MVC 구조

• 디자인 패턴 중 하나로, Model - View - Controller의 약자로서 어플리케이션이나 프로젝트 구성 시 각각의 3가지 역할을 구분하는 아키텍처 패턴이다.

MODEL : 비지니스 로직 및 DB 연동 등을 통한 data 처리, 저장, 관리 수행.

• 요청에 맞는 업무 수행를 수행, 상태 변화 시 view와 controller에게 알림.
• 뷰나 컨트롤러에 대해서 어떠한 정보도 가지지 않음.
• ex) domain class(DTO, VO), BO, DAO, manager class 등.

VIEW : UI 및 presentation 로직

• 사용자 요청에 대한 처리 결과를 화면에 출력.
• 모델에 대한 정보를 따로 저장해선 안됨.
• 모델이나 컨트롤러에 대한 정보를 가지지 않음.
• 재사용이 가능하게 설계하면 good

CONTROLLER : 사용자와 model, view 사이의 실행 흐름 제어

• 요청을 받을 경우 실제 업무를 수행하는 모델을 호출 & 결과를 view로 전달하는 역할
• 모델로 정보를 넘길 때 데이터 가공을 하기도,,
• model와 view 사이의 중재자이기에, 둘의 존재를 앎.

처리 순서 : 사용자(요청) -> c -> m -> c -> v (응답)

장점 :

• 각 역할 별로 코드를 분리함으로서 각 기능에만 집중 가능. 관련 처리에 관해서 효율적이다. _ 부속 간 의존성이 낮아지고, 로직이나 화면을 수정 시 서로에게 영향을 주지 않고 수정할 수 있음.
• 유지보수에 용이하고, 확정성이나 재사용성이 높음.
• 뷰와 비지니스 로직이 분리가 되는 만큼 디자이너와 개발자 사이 분업이 가능.

단점 :

• 설계 시간이 꽤 소요됨.
• MVC에서 view는 controller에 연결되어 화면을 구성.
  (view와 controller는 n : 1의 관계 )
  즉 controller는 view의 lifecycle과 강하게 연결되며 분리가 어렵.
• 결과적으로 model과 view 사이에 의존성을 띄우게 됨.
  _서로간의 의존성 완전히 없앨 수 없음.
• 규모가 커질 수록 mvc 구조는 어쩔 수 없이 controller의 많은 양의 로직이 몰리게 됨.
• 이 경우 화면이 복잡할 경우 역으로 유지보수나 확장이 어려워지고, 테스트하기도 어렵게 됨. << massive view Controller라는 말이 있을 정도....

추가 :

위의 의존성이 높아질 수 있는 mvc의 단점을 보완하기 위하여 mvc 패턴을 기초로서 파생된 mvvm 패턴이나 mvp 패턴이 등장. 이들의 기초가 되는 만큼, 일단 mvc 이해하는 것 중요.