MVC패턴 (Model-View-Controller Pattern)
“화면을 그리는 것(View)”과 “비즈니스 규칙(Model)”을 “흐름 제어(Controller)”로 느슨하게 분리해 관심사 분리(Separation of Concerns) 를 달성하는 아키텍처 패턴
즉, 모델, 뷰, 컨트롤러라는 개념으로 역할을 나누어 작업을 처리하는 방법이다.
모델, 뷰, 컨트롤러의 관계
사용자의 요청을 받으면 컨트롤러는 모델을 통해 데이터를 가져오고, 그 정보를 바탕으로 뷰에서 시각적인 부분을 제어해 사용자에게 전달하게 된다.
정리하자면
클라이언트가 요청(Request)을 컨트롤러로 보낸다.
Controller는 Service를 호출해 Repository로 DB 조회해 데이터를 가져온다.
Model에 저장된 데이터를 바탕으로 시각적 요소 출력을 담당하는 View를 제어해 사용자에게 전달한다.
이렇게 MVC 패턴의 세 가지 구성 요소는 명확하게 정의된 역할을 수행하며 상호작용을 한다.
모델(Model)
애플리케이션의 핵심 데이터와 비즈니스 로직
예를 들어 화면안의 박스에 글자를 표현한다면, 박스의 위치 정보, 글자의 내용, 글자의 위치 등의 정보를 가지고 있어야 하는 것이다.
- 데이터 저장소(DB)와 상호작용한다.
모델이 가지는 규칙
- 사용자가 편집하고자 하는 모든 데이터를 가지고 있어야 한다.
- 독립적으로 작동하며, 뷰와 컨트롤러와 관련된 코드가 포함되면 안된다.
- 재사용이 가능해야 하며, 다른 인터페이스에서도 불변해야한다.
뷰(View)
사용자에게 보여지는 애플리케이션 UI.
모델에 담겨있는 데이터를 사용자에게 시각적으로 보여주기 위해 화면을 구성하고, 입력을 컨트롤러에 전달한다.
뷰가 가지는 규칙
- 모델이 가지고 있는 정보를 임의로 저장하면 안된다.
- 뷰 내부에는 모델의 코드는 있을 수 있지만, 컨트롤러의 코드가 포함되면 안된다.
- 뷰가 모델로 부터 데이터를 받을 때는, 사용자마다 다르게 보여줘야 하는 데이터에 한해 받을 수 있다.
- 재사용이 가능해야 한다.
컨트롤러(Controller)
사용자 입력을 처리하고, 모델과 뷰 사이에서 애플리케이션의 전체적인 흐름을 관리한다.
뷰에서 전달된 사용자 입력을 분석하여 적절한 모델 기능을 호출하고, 데이터를 처리한 결과를 다시 뷰에 전달해 화면에 표시하도록 한다.
즉, 컨트롤러는 모델과 뷰의 역할을 분리하는 중요한 역할을 하는 것.
컨트롤러가 가지는 규칙
- 모델과 뷰의 코드가 포함되어도 된다. (의존)
- 모델과 뷰의 변경을 모니터링 해야 한다.
- 뷰가 모델로부터 데이터를 받을 때, 반드시 컨트롤러에서 받아야 한다.
그렇다면 왜 이렇게 역할을 나누게 되었을까?
MVC 패턴의 등장 배경
초창기에는 한 파일 안에 모든 코드를 작성하다보니 유지보수를 하는 데에 불편함이 생겼고, 이를 해결하기 위해 등장한 것이 MVC 패턴이다.
유지보수가 편한 코드
특정 기능을 추가하거나 수정할 때 최소한의 코드만을 수정해 기능을 변경할 수 있는 코드
MVC 패턴의 이점
- 컴포넌트의 명확한 역할 분리로 서로간의 결합도를 낮출 수 있다.
- 코드의 재사용성, 확장성을 높일 수 있다.
- 서비스의 유지보수와 테스트가 용이하다.
- 여러 개발자가 각 부분을 나누어 동시 개발할 수 있어 개발 속도가 향상된다.
MVC 패턴의 단점
(MVC의 단점 때문에 MVC를 사용하지 않을 일은 없으니 그냥 알아만 두면 된다.)
- 코드의 전체적 처리 과정의 이해를 위한 배경지식이 필요하다.
- 코드의 일관성을 유지해야 한다.
5 Layer
현대는 MVC에서 조금 더 세분화된 5 Layer를 사용한다.
단순히 MVC 패턴만 사용하게되면 컨트롤러가 비대해지고, 중복 로직, 데이터베이스 처리등의 모든 코드를 3개의 레이어만으로 처리하기 어렵기 때문이다.
Presentation Layer
- 사용자에게 보여주는 화면, UI
Control Layer
- 컨트롤러
- Presentation Layer 와 Business Logic Layer를 연결
- Service 레이어를 호출
Business Logic Layer
- Service
- 비즈니스 로직을 별도의 Service 객체에서 구현하고, 컨트롤러가 서비스 객체를 사용해 요청을 처리한다.
- Transaction의 시작점
- Controller와 Persistance Layer의 중간 다리 역할
- Persistance Layer로 값을 저장하거나, 가져오는 역할
- Domain
- 데이터와 행위를 갖는 객체 ex) 요리의 재료 또는 재료를 모은 음식
- 핵심 비즈니스 로직을 가진다.
- 주요 검증이 필요한 로직으로 TDD로 집중 관리되어야 한다.
- Persistance Layer에 매핑된다.
Persistance Layer
- 데이터베이스
- 데이터에 접근하는 기능을 별도의 Repository나 DAO 객체에서 구현
- 영속성
- CRUD처리 (+ 페이징, 정렬)
Domain Model Layer
- 각 계층 사이에서 전달되는 객체
- 대부분 도메인 모델을 DTO로 사용한다.
- Data Transfer Object
컨트롤러→서비스→모델 관련 처리→영속성 처리→결과를 컨트롤러에 반환의 흐름으로 처리된다.
[참고] https://bsnippet.tistory.com/13, 우아한 테크 코스 강의
