SPRING

MVC 패턴 - FrontController?

고민말고생각하는사람 2024. 8. 21. 18:27

MVC패턴?

Model, View, Controller 의 3계층으로 나눈 패턴이다.

 

Model - 상태, 동작을 수행하고 데이터 전송,  주요 임무로 하는 계층. 컨트롤러에서 담고, view에서 참조한다.

View - 클라이언트에게 컨텐츠를 시각화해주는 계층

Controller - 흐름 제어, 수문장 역할을 해주는 계층 이다. 적절한 Model, View를 선택한다.

 

계층을 나눈 이유?

1. 하나로 뭉쳐두면, 역할도 책임도 불분명하다.

2. 유지보수가 정말 복잡하고 번거롭고 짜증난다.

 

mvc 패턴은 크게 1,2로 나뉜다.

 

MVC 패턴1

컨트롤러가 클라이언트에서 받아온 데이터를 Model에 담고

View 에서 해당 Model 을 참조하여 시각화하여,

클라이언트에게 응답하는 패턴이다.

 

요청을 처리하고 전송하는 Model 계층과 View를 직접적으로 연결하는데, 이런 행위가 Controller 계층에서 전부 이루어진다.(Controller 의 역할이 너무 많다)

클라이언트의 request -> Controller -Model(데이터 전달) - 

-> View(모델 데이터 참조) -> 클라이언트로 response

 

MVC 패턴2

클라이언트의 요청을 받고,

컨트롤러가 비지니스 로직을 수행한 결과를 받아,

  해당 결과물(데이터)를 모델에 담고,

  View로 전송하고,

view에서 해당 모델의 데이터를 읽어 클라이언트에게 응답하는 패턴이다.

 

MVC 패턴1에선 controller가 너무 많은 역할을 수행한다. (흐름제어, 요청 처리, 결과 대입. 조건에 맞는 view 탐색, 전달 등 등)

클라이언트의 request -> Controller - Service, Repository-> Controller ->
-Model(데이터 전달) - 

-> View(모델 데이터 참조) -> 클라이언트로 response

 

 


해보자.

-after a hour later-

servlet, jsp로 계속 진행해보니, 

 

중복되는 코드, 불필요한 코드 등이 너무 많았다.

ex)

dispatcherServlet 을 계속해서 호출해야하고, ServletRequest, ServletResponse 쓰지 않을 때도 계속해서 넘겨야 한다.

 

또,

Servlet 자체가 url을 받아 동작하는 구조이기 때문에

Servlet을 계속해서 만들어야 하는 단점이 있었다.

 

한 군데에서 다 처리하고 Controller 에서는 흐름 제어, 데이터 전달만 할 수 있도록 군집시킬 순 없을까?

 

동작 1개 할 때마다 WebServlet 을 새로 작성하는 것은 굉장히 비효율적이다.

 

이를 극복하기 위해, FrontController 가 등장했다.

 


FrontController

FrontController. 말 그대로 Controller 앞에 있는 장치이다.

FrontController 는 Controller에 진입하기 위한 수문장 역할로, 중복되는 코드를 일괄 처리 해주며, url, 요청 method 등에 따라 필요한 컨트롤러와 그 메서드를 호출해준다.