티스토리 뷰

프톤트 컨트롤러 패턴

이전의 컨트롤러의 역할을 보면 중복되는 코드가 많다. (뷰로 이동과 같은)

그래서 컨트롤러에 접근하기 전, 프론트 컨트롤러를 통해 공통 처리를 하고 온다.

프론트 컨트롤러를 제외한 나머지 컨트롤러는 서블릿을 사용하지 않아도 된다.

프론트 컨트롤러를 거쳐 컨트롤러로 접근하는 모습

v1 구현 - 프론트 컨트롤러 도입

프론트 컨트롤러의 코드

urlPatterns = /fron-controller/v1의 하위 경로들은 모두 이 서블릿을 접근하게 된다.

controllerMap에 저장된 URI를 통해 controller 변수에 각 컨트롤러가 호출된다.

-> 중복되는 코드를 줄일 수 있었다.

JSP는 이전의 코드를 그대로 사용한다.

 

v2 구현 - 뷰 분리

뷰(jsp)로 이동하기 위해 모든 컨트롤러에 아래와 같은 코드가 반복된다.

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

 

이 몯든 컨트롤러에서 반복되는 작업들을 프론트 컨트롤러가 작업해준다면 훨 깔끔해고 간결한 코드가 완성될 것이다.

프론트 컨트롤러가 MyView를 반환받고 정보를 토대로 JSP 호출

 

v3 구현 - 모델 추가

위 컨트롤러의 경우 Controller 인터페스를 상속받은 것인데, Requset와 Response를 사용하는 경우가 없다.

단지 파라미터가 필요한 것이다. 그렇기에 컨트롤러에서 서블릿을 분리하는 과정이 필요하다.

request,response에는 데이터 저장 기능이 있다고 했는데, 이를 Model 객체를 만들어 데이터를 전달하면 된다.

 

또한, viewPath를 보면 실제 물리 위치가 저장되는데, 이를 논리 이름으로 반환하여 이름 중복을 제거한다.

컨트롤러에서 로직을 수행하고, ModelView 객체를 넘기고 이를 viewResolver 메서드를 통해 논리 이름을 생성한다.

 

v4구현 - 단순한 컨트롤러

위 v3는 이론적으로 훌륭하다. 하지만 개발자가 사용하기 불편한 점이 있다 -> ModelView객체를 생성, 관리.. 등

프레임워크 아키텍처는 단순하고 편리해야한다.

컨트롤러에서 ModelView 객체가 아닌, 그냥 ViewName을 반환한다.

이를 위해 모델 객체를 프론트 컨트롤러에서 생성해서 컨트롤러에 넘겨준다.

 

v5구현 - 유연한 컨트롤러

현재는 controllerMap에 String과 Controller를 지정하여 개발하고 있었다.

그런데 v4 와 v3을 번걸아가며 쓰고 싶다면 어떻게 해야 하는가? 인터페이스가 다른데 호환이 가능한가? 이럴때 사용하는게

어댑터 패턴

충전기를 보면 usb타입과 c타입으로 변환해주는 어댑터가 있다. 이 패턴도 마찬가지다.

핸들러 어댑터 : 다양한 종류의 컨트롤러를 호출할 수 있게 해준다.

핸들러 : 컨트롤러의 더 큰 범위, 한정되지 않는 종류를 처리할 수 있기에 범위를 확장했다.

 

 

 

 

 

 

본 포스팅은 인프런 강의 김영한님의

[ 스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술 ] 을 수강하며 작성한 내용입니다.

공지사항
최근에 올라온 글
최근에 달린 댓글
«   2025/02   »
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28