하나의 서블릿이나 JSP만으로 비즈니스 로직과 뷰 렌더링까지 처리한다면 너무 많은 역할을 하게 된다. 이는 결과적으로 유지보수에 어려움을 준다. MVC 패턴은 이를 해결해준다.

⭐️ MVC 패턴?

---

MVC(Model-View-Controller) 패턴은 하나의 서블릿이나 JSP로 처리하던 것을 Controller와 View 영역으로 역할을 나눈 것이다.
웹 애플리케이션은 보통 MVC 패턴을 사용한다.

📌 MVC 패턴 동작 방식

1. 클라이언트가 웹 서버에 웹 애플리케이션 실행을 요청한다.
2. 서버는 들어온 요청을 처리할 수 있는 Controller를 찾아서 요청을 전달한다.
3. Controller는 파라미터를 꺼내고 HTTP 요청이 맞는지 확인한다.
4. 이때 로직이 맞지 않다면 400오류 등을 반환하고, 로직이 맞다면 Service, Repository 등을 호출해서 저장, 주문, 호출 등의 로직을 실행한다.
5. 그 결과를 Controller 로직이 받아서 Model에 데이터를 전달한다.
6. View 로직이 제어권을 넘겨받고 Model의 데이터를 참조해서 출력(응답)을 한다.
숫자는 위 그림의 숫자와 연관이 없습니다.

📌 Controller, Model, View

---

✔︎ Conroller

Controller는 데이터와 사용자 인터페이스 요소들을 잇는 다리 역할을 한다. HTTP 요청을 받아서 parameter를 검증하고, 비즈니스 로직을 실행한다. 그리고 뷰에 전달할 결과 데이터를 조회해서 Model에 담는다.

Controller는 다음과 같은 규칙을 가진다.
1. Model, View에 대해서 알고 있어야 한다.

• Model, View는 서로의 존재를 모르고 변경을 외부로 알리고 수신하는 방법만 가진다. 이를 Controller가 중재하기 위해 Model과 View에 대해서 알고 있어야한다.

2. Model이나 View의 변경을 모니터링 해야 한다.

• Model이나 View의 변경 통지를 받으면 이를 해석해서 각각의 구성 요소에게 통지를 해야 한다. 또한, 애플리케이션의 메인 로직은 Controller가 담당한다.

✔︎ Model

Model은 View에 출력할 데이터를 담아둔다. View가 필요한 데이터를 모두 Model에 담아서 전달해주는 덕분에 View는 비즈니스 로직이나 데이터 접근을 몰라도 되고, 화면을 렌더링 하는 일에 집중할 수 있다.

Model은 다음과 같은 규칙을 가진다.
1. 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야 한다.
2. View, Controller에 대해서 몰라야한다.

• 데이터 변경이 일어났을 때 Model에서 화면 UI를 직접 조정해서 수정할 수 있도록 View를 참조하는 내부 속성 값을 가져선 안된다.

3. 변경이 일어나면, 변경 통지에 대한 처리 방법을 구현해야 한다.

• Model 속성 중 변경이 발생하면 이를 전달해야하며, 변경 요청을 받았을 때 이를 수신할 수 있는 처리 방법을 구현해야한다.

✔︎ View

View는 모델에 담겨있는 데이터를 사용해서 input Text, 체크 박스 등의 사용자 인터페이스 화면을 그리는 일에 집중한다. 즉, 데이터를 기반으로 사용자들이 볼 수 있는 화면이다.

View는 다음과 같은 규칙을 가진다.
1. Model이 가지고 있는 정보를 따로 저장해서는 안된다.

• View는 위 동작 방식에서 본 것처럼 Model의 데이터를 참조한다. View는 이 데이터를 유지하기 위해서 View 내부에 데이터를 저장해서는 안된다.

2. Model, Controller 등 다른 구성 요소를 몰라야 한다.

• Model과 마찬가지로 View 자신 말고 다른 요소를 참조하거나 어떻게 동작하는지 알면 안된다. View는 그저 Model의 데이터를 참조해서 화면에 표시해주는 역할이다.

3. 변경이 일어나면, 변경 통지에 대한 처리 방법을 구현해야 한다.

• View 속성 중 변경이 발생하면 이를 전달해야하며, 변경 요청을 받았을 때 이를 수신할 수 있는 처리 방법을 구현해야한다. View는 화면에서 사용자가 내용을 변경하면 이를 Model에 전달해서 Model을 변경해야한다.

📌 MVC 패턴의 한계

MVC 패턴을 적용한 덕분에 Controller의 역할과 View를 렌더링 하는 역할을 명확하게 구분 할 수 있었다. 그러나 여전히 Controller는 중복이 많고, 불필요한 코드들도 많이 존재한다.

View는 Controller에 연결되어서 화면을 구성하므로 다수의 View를 가질 수 있다. 또한, Model은 Controller를 통해서 View와 연결되지만, Controller에 의해서 하나의 View에 연결될 수 있는 Model도 여러 개가 될 수 있기에 View와 Model이 서로 의존성을 띄게 된다. 즉, Controller에 다수의 Model과 View가 복잡하게 연결되어 있는 상황이 발생할 수도 있다.

---

• forward 중복
  MVC 패턴은 Controller에서 View로 이동하는 아래와 같은 코드가 항상 중복적으로 호출이 된다.

String viewPath = "/WEB-INF/...";
RequestDispatcher dispatcher = request.getRequestDispatcher(viewPath);
dispatcher.forward(request, response);

• 공통 처리가 어렵다.
  기능이 복잡해질수록 Controller에서 공통으로 처리해야 하는 부분이 점점 더 많이 증가한다. 단순히 공통 기능을 메서드로 뽑으면 될 것 같지만, 결과적으로 이 메서드로 항상 호출하는 것 자체도 중복이다.

즉, MVC 패턴은 공통 처리가 어렵다는 문제가 있다. 이 문제를 해결하기 위해서는 Controller 호출 전에 먼저 공통 기능을 처리해야 한다. 이는 Front Controller 패턴으로 해결할 수 있다.
스프링 MVC의 핵심도 바로 Front Controller에 있다.

틀린 내용에 대한 지적은 언제나 환영합니다!

---

출처
김영한님의 스프링 MVC
https://cocoon1787.tistory.com/733
https://m.blog.naver.com/jhc9639/220967034588