MVC

MVC

Model View Controller

만들어진 배경

코드가 많아지면 많아질수록 유지보수가 힘들어짐
코드를 각각 데이터 관리, 중재자, 보여주기 등 기능에 따라 정리
└보다 효율적인 유지보수가 가능한 MVC 패턴 탄생

Model

1. 데이터베이스와 직접적으로 통신, 데이터베이스에서 받은 데이터를 Controller로 전달하는 역할
2. 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야 함
3. 뷰나 컨트롤러에 대해서 어떤 정보도 알지 말아야 함
4. 변경이 일어나면 변경 통지에 대한 처리방법을 구현해야 함

Controller

1. Model로부터 받은 데이터를 View에 전달, 클라이언트 측으로부터 받은 요청을 처리
2. 모델이나 뷰에 대해서 알고있어야 함
3. 모델이나 뷰의 변경을 모니터링해야함

View

1. Controller로부터 받은 데이터를 표시
2. 모델이 가진 정보를 따로 저장해선 안됨
3. 자신 이외의 요소는 참조하거나 동작하면 안됨
4. 변경이 일어나면 변경 통지에 대한 처리방법을 구현해야 함

패턴의 예시

client에서 data 요청
controller에서 라우팅, 요청을 model로 넘김
model이 db에서 정보를 가져와서 controller에 넘김
controller에서 응답을 보냄
view에서 받아서 UI로 표시

요청 : UI > controller > model > db
응답 : model > controller > UI

MVC를 지키면서 코딩하는 방법

1. 모델은 컨트롤러와 뷰에 의존하지 않아야 함. 즉 모델 내부에 컨트롤러와 뷰에 관련된 코드가 있으면 안됨
   └즉 컨트롤러와 뷰에서 코드를 import해 오면 안됨 (각각 독립적으로, 모델은 데이터 관련 코드만)
2. view는 model에만 의존해야 하고 controller에 의존하면 안됨
   (view 내부에는 model 관련 코드만 있어야하고 controller 관련 코드는 있으면 안됨)
3. controller는 model과 view에 의존해도 됨(controller 내부에는 model과 view의 코드가 있을 수 있음)
4. view가 model로부터 데이터를 받을 때 반드시 controller에서 받아야 함

MVC의 장점

1. 기능별로 코드를 분리하여 하나의 파일에 코드가 모이는 것을 방지하여 가독성과 코드의 재사용성이 증가
2. 각 구성요소들을 독립시켜 협업을 할 때 맡은 부분의 개발에만 집중할 수 있어 개발의 효율성을 높여줌 (분업을 가능하게)
3. 개발 후에도 유지보수성과 확장성이 보장

MVC의 한계

Model과 View는 서로의 정보를 갖고 있지 않는 독립적인 상태라고 하지만 Model과 View사이에는 Controller를 통해 소통을 이루기에 의존성이 아예 없을 수는 없음. 그래서 복잡한 대규모 프로그램의 경우 다수의 View와 Model이 Controller를 통해 연결되기 때문에 컨트롤러가 불필요하게 커지는 현상이 발생하기도 합니다. 이러한 현상을 Massive-View-Controller현상이라고 하며 이를 보완하기 위해 MVP, MVVM, Flux, Redux등의 다양한 패턴들이 등장