📌 MVC 패턴

MVC 패턴

• 디자인 패턴
• Model View Controller 3가지로 구분한 패턴
• 유지보수가 편해지는 코드 구성 방식

웹 애플리케이션 아키텍쳐의 역사

(JSP로 구성한) 웹 애플리케이션의 아키텍쳐 : 모델1

• 구성 : JSP + JavaBeand(Service)
• 뷰와 로직이 섞임
• 장점 : 구조가 단순
• 단점 : 출력과 로직 코드가 섞여 유지보수가 어렵다.

(JSP로 구성한) 웹 애플리케이션의 아키텍쳐 : 모델2

• 구성 : JavaBean(Service) + JSP + 서블릿
• MVC 구조
• 장점 : 뷰와 로직이 분리되어 유지보수가 쉽다.
• 단점 : 복잡하므로 작은 프로젝트에서는 오히려 과할 수 있다.

MVC 흐름

1. 사용자는 원하는 기능을 처리하기 위한 모든 요청을 컨트롤러에 보낸다.
2. 컨트롤러는 모델을 사용하고, 모델은 알맞은 비즈니스 로직을 수행한다.
3. 컨트롤러는 가용자에게 보여줄 뷰를 선택한다.
4. 선택된 뷰는 사용자에게 알맞는 결과 화면을 보여준다. 이 때 사용자에게 보여줄 데이터는 컨트롤러를 통해서 전달받는다.

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의 코드가 있을 수 있다.

View가 Model로부터 데이터를 받을 때, 반드시 Controller에서 받아야 한다.

참고 자료

• [10분 테코톡] 🧀 제리의 MVC 패턴
• [10분 테코톡] 👩🏻‍💻👨🏻‍💻해리&션의 MVC 패턴