2021-05-26글
[10분 테코톡] 🧀 제리의 MVC 패턴, [10분 테코톡] 👩🏻💻👨🏻💻해리&션의 MVC 패턴을 들으며 정리한 글입니다.
MVC 패턴
- 디자인 패턴
- Model View Controller 3가지로 구분한 패턴
- 유지보수가 편해지는 코드 구성 방식
웹 애플리케이션 아키텍쳐의 역사
(JSP로 구성한) 웹 애플리케이션의 아키텍쳐 : 모델1
- 구성 : JSP + JavaBeand(Service)
- 뷰와 로직이 섞임
- 장점 : 구조가 단순
- 단점 : 출력과 로직 코드가 섞여 유지보수가 어렵다.
(JSP로 구성한) 웹 애플리케이션의 아키텍쳐 : 모델2
- 구성 : JavaBean(Service) + JSP + 서블릿
- MVC 구조
- 장점 : 뷰와 로직이 분리되어 유지보수가 쉽다.
- 단점 : 복잡하므로 작은 프로젝트에서는 오히려 과할 수 있다.
MVC 흐름
- 사용자는 원하는 기능을 처리하기 위한 모든 요청을 컨트롤러에 보낸다.
- 컨트롤러는 모델을 사용하고, 모델은 알맞은 비즈니스 로직을 수행한다.
- 컨트롤러는 가용자에게 보여줄 뷰를 선택한다.
- 선택된 뷰는 사용자에게 알맞는 결과 화면을 보여준다. 이 때 사용자에게 보여줄 데이터는 컨트롤러를 통해서 전달받는다.
Model
- 값과 기능을 가지고 있는 객체
- 비즈니스 로직을 수행
View
- 모델에 포함된 데이터의 시각화
Controller
- 모델 객체로의 데이터 흐름을 제어
- 모델과 뷰의 중개자 역할
- 뷰와 모델의 역할을 분리
Why MVC?
- 각 컨포넌트의 코드 결합도를 낮출 수 있음
- 코드의 재사용성을 높일 수 있음
- 구현자들 간의 커뮤니케이션 효율성을 높일 수 있음
MVC 많이 실수하는 부분들...
Model에서 View의 접근 또는 역할 수행
- 도메인에서 비즈니스 로직이 아닌 출력에 대한 로직은 별도로 분리하자
- ex) toString()
View에서 일어나는 과한 값 검증과 예외처리
- View에서 검증을 하면 뒤의 로직은 신경쓰지 않아도 되니 편리하다고는 느낄 수 있음
- 하지만 단일 책임 원칙을 위반함 (입력 채널이 달라질 경우 유효성 테크 로직도 옮겨야함)
- 값 형식은 유효하지만, 도메인 모델에서 확인해야할 부분들은 생성자에서 체크
- ex) 이름은 몇 글자 이상이어야 한다.
View에서 일어나는 비즈니스 로직
- 모델을 생성하거나 모델끼리 연산을 하는 로직
Controller는 최대한 가볍게
- 로직은 최대한 배제하고 model과 view의 연결 역할만 하도록 구현
Service의 등장 (지금은 이런게 있구나 정도만 )
Controller에서 중복이 발생한다.
- 별도의 객체로 분리
- 별도의 메서드로 분이
이러다 서비스 레이어가 추가되었다!
Service란?
- 비즈니스 로직을 수행하는 메서드를 가지고 있는 객체
- 비즈니스 메서드를 별도의 서비스 객체에서 구현하도록 하고 컨트롤러는 서비스 객체를 사용
- 하나의 트랜잭션을 가짐
MVC를 지키면서 코딩하는 방법
Model은 Controller와 View에 의존하지 않아야 한다.
- Model 내부에 Controller와 View에 관련된 코드가 있으면 안됨
- model은 데이터와 관련된 코드이니 언제든지 정제된 코드만 꺼내쓸 수 있도록
View는 Model에만 의존해야하고, Controller에 의존하면 안된다.
- View 내부에 Model의 코드만 있을 수 있고, Controller의 코드가 있으면 안됨
Vuew가 Model로부터 데이터를 받을 때는 사용자마다 다르게 보여주어야 하는 데이터에 대해서만 받아야 함
빨간 부분이 사용자마다 다르게 보여져야하는 부분이다.
또는 자동차 경주 게임에서 -(대시) 같은 경우
View는 사용자한테 보이는 UI와 모델로부터 받은 데이터가 합쳐지는 부분이다.
Controller는 Model과 View에 의존해도 된다.
- Controller 내부에는 Model과 View의 코드가 있을 수 있다.
