[프로젝트 리뷰] MVC에 대하여 겪었던 고민

MVC패턴을 접함

JAVA를 처음 배우던 시절부터 MVC에 대한 기본적인 설명을 듣고 알고는 있었으나, 당시에는 이중 for문을 겨우 돌리고 짝짝짝 박수를 칠 때라 (비유이긴하지만..어느정도는..) 정말 알려주는 것을 그대로 알기만 할 뿐, 더이상의 의문이나 탐구 욕구가 생길 새가 없던것같다.
그저 많이 사용한다고 하니, 그냥 그런가보다 하고 진리처럼 알고있던 것 같다.

MVC패턴을 잠시 정리하고 넘어가면 다음과 같다

Model, View Controller 의 약자로, 애플리케이션을 세가지의 역할로 구분한 개발 방법론이다.

Controller : 사용자가 접근 한 URL에 따라서, 사용자의 요청사항을 파악한 후에 그 요청에 맞는 데이터를 Model에 의뢰하고, 데이커를 View에 반영해서 사용자에게 알려준다.

Model : 일반적으로 모델은 데이터베이스 테이블에 대응된다. 이를테면 Topic이라는 테이블은 topic_model이라는 model을 만든다. 그런데 이 관계가 강제적이지 않기 때문에 일관성 있게 정의하는 것이 필요하다.

View : View는 클라이언트 측 기술인 html/css/js들을 모아둔 컨테이너이다.

또, Spring Framework를 사용하면서도, "Service레이어와 Service implement를 이렇게 생성해서 이렇게 쓰면되요" 라는 선생님 말씀에도 "이걸 왜 쓰고있는 것이지?" 라는 의문보단, "Framework가 제어의 역전이 일어나니, 시키는대로 하는게 맞겠지!" 라는 나 좋을대로의 결론을 내려버렸던것같다.

MVC는 Controller, Model, View로 분리한 것이 기본인데 거기에 Service layer 까지 얹어 쓰는구나! 라고 생각하고 말았떤 나날들

대혼동

이렇게 알고있던 내게, 코드스테이츠를 다니며 스프린트 시간에 재접한 MVC패턴은 솔직히 동공의 지진 대혼동의 파티 였다..!
Sequize로 entity를 model에서 정의 할 뿐, Controller에서 DB에 접근하고 VO도, DAO도 존재하지 않았다. (너무 JAVA기반적인 생각이긴 했지만)
이게 어떻게 MVC패턴일까? 오피스 아워 때에 질문을 했을 때 돌아오는 답은
ORM을 활용 할 시에 해당 ORM의 철학이나 구현방식에 따라 달라질 수 있고, sequlize의 경우 MVC패턴의 구현에 초점을 둔다면 Controller에서 접근하는것도 가능할 것이라는 것이었다.
MVC와 같은 아키텍쳐는 방법론적이기 때문에 추가적인 레이어를 활용 할 수 있다는 것이었다.

더 흔들리는 동공..

그렇다면 정말 극단적으로 model에 entitiy와 ormconfig.json만 존재하여도 MVC모델을 충족하였다고 할 수 있나? MVC 패턴의 최소 충족 조건은 무엇인가?

이렇게 개념이 명확하지 않은 상태에서 express 프로젝트를 MVC패턴으로 나누려고 하니, 정말 많은 의아함이 들었다.

역시 내가 여기에서 의문이 일어나는 이유는, 내가 개념에 대하여 명확히 모르기 때문일것이다.
요새에 면접을 준비하면서 정말 많이 느끼는 것이, 그냥 코딩을 잘 하는 것과 설명은 완전 별개의 영역인 것이다.
그리고 설명을 잘 못하는 것은 잘 몰라서 이고, 그렇게 되면 코딩에서도 확장성이 확실히 떨어진다는 생각이 많이든다.

---

디자인 패턴, MVC모델

소프트웨어 개발 방법에서 사용되는 디자인패턴은, 프로그램 개발에서 자주 나타나는 과제를 해결하기 위한 방법 중 하나로, 과거의 소프트웨어 개발 과정에서 발견된 설계와 노하우를 축적하여 이름을 붙여, 이후에 재이용하기 좋은 형태로 특정의 규약을 묶어서 정리한 것이다.
알고리즘과 같이 프로그램 코드로 바로 변환 될 수 있는 형태는 아니지만, 특정한 상황에서 구조적인 문제를 해결하는 방식을 설명해준다.

디자인 패턴에 대한 정의는 위와 같다.
MVC도 디자인 패턴중에 하나로, 이 패턴을 성공적으로 사용하면, 사용자인터페이스로 부터 비즈니스 로직을 분리하여 애플리케이션의 시각적 요소나 그 이면에 실행되는 비즈니스 로직을 서로 영향없이 쉬게 고칠 수 있는 애플리케이션을 만들 수 있다.
(비즈니스 로직_Business login 은 컴퓨터 프로그램에서 실세계의 규칙에 따라 데이터를 생성, 표시, 저장, 변경하는 부분을 일컫는다.)

비즈니스 로직은 이론적으로 3티어 구조에서 가운데 티어를 차지한다.

MVC에 대한 가이드라인

• 모델
  1. 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야만 한다.
  2. 뷰나 컨트롤러에 대해 어떤 정보도 알지 말아야 한다.
  3. 변경이 일어나면, 변경 통지에 대한 처리 방법을 구현해야만 한다.
     모델의 속성 변경 중 텍스트 정보가 변경되면, 이벤트를 발생시켜 누군가에게 전달해야 하며, 누군가 모델을 변경하도록 요청하는 이벤트를 보낼 을 때 이를 수신 할 수 있는 처리방법을 구현해야 한다.
• 뷰
  1. 모델이 가지고 있는 정보를 따로 저장해서는 안된다.
  2. 모델이 컨트롤러와 같이 다른 구성 요소를 몰라야 된다.
  3. 변경이 일어나면, 변경 통지에 대한 처리 방법을 구현해야만 한다.
• 컨트롤러
  1. 모델이나 뷰에대해서 알고있어야 한다.
  2. 모델이나 뷰의 변경을 모니터링 해야한다.

mvc에 대한 가이드라인을 찾아보면서 느낀점은, 어느 것을 기준으로 했느냐에따라 가이드 라인이 조금씩 다르나는 것이다.
하지만 여러 가이드를 읽으면서, 중요한점은 MVC의 핵심은 결국 같다는 것이다.

글이 길어지는것 같아 중간에 끊으려고 한다.
이어서 쓰는 글에는 Java와 Spring 을 기준으로 MVC를 및 용어를 명확히 정리하려고 한다.
(JAVA기반 개발을 더 선호한다기 보단, 하나라도 잘해야 확장과 정리가 쉬워서..^^;;)

---

참조

모델-뷰-컨트롤러