프론트 컨트롤러
- 프론트 컨트롤러 서블릿 하나로 클라이언트 요청을 받음
- 프론트 컨트롤러가 요청에 맞는 컨트롤러를 찾아 호출
- 공통 처리 가능
- 프론트 컨트롤러를 제외한 나머지는 서블릿을 사용하지 않아도 됨
V1
구조
문제점
String viewPath = "/WEB-INF/views/new-form.jsp";
RequestDispatcher dispatcher = request.getRequestDispatcher(viewPath);
dispatcher.forward(request, response);모든 컨트롤러에서 뷰로 이동하는 부분에 중복이 있음
V2
구조
프론트 컨트롤러의 도입으로 MyView 객체의 render() 를 호출하는 부분을 모두 일관되게 처리할 수 있다. 각각의 컨트롤러는 MyView 객체를 생성만 해서 반환하면 된다.
문제점
서블릿 종속성 : 컨트롤러의 입장에서는 HttpServletRequest, HttpServletResponse가 필요 없음. Model 객체를 만들어 주고 받으면컨트롤러가 서블릿 기술을 사용할 필요 없음.
뷰 이름 중복 : 컨트롤러가 뷰의 논리 이름을 반환하고 실제 물리 위치는 프론트 컨트롤러에서 처리하도록 단순화하자. 이러면 나중에 뷰의 폴더 위치가 바뀌어도 프론트 컨트롤러만 고치면 된다.
- /WEB-INF/views/new-form.jsp -> new-form
- /WEB-INF/views/save-result.jsp -> save-result
- /WEB-INF/views/members.jsp -> members
V3
구조
뷰 리졸버 : 컨트롤러가 반환한 논리 뷰 이름을 실제 물리 뷰 이름으로 변경한다. 그리고 실제 물리 경로가 있는 MyView를 반환한다.
문제점
V3는 잘 설계된 컨트롤러 이지만 실제 개발자 입장에서 항상 ModelView 객체를 생성하고 반환해야 하는 부분이 번거롭다.
V4
변경점
모델 객체 전달
모델 객체를 프론트 컨트롤러에서 생성해서 넘겨준다.
뷰의 논리 이름을 직접 반환
컨트롤러가 ModelView를 반환하지 않고 ViewName만 반환한다.
V5
어떤 개발자는 V3 방식을 사용하고 싶고 어떤 개발자는 V4 방식을 사용하고 싶어함. 그럴때는 어댑터 패턴을 사용해서 프론트 컨트롤러가 다양한 컨트롤러를 처리할 수 있게 만들어준다.
핸들러 어댑터 : 중간에 어댑터 역할을 해줘서 다양한 종류의 컨트롤러를 호출 할 수 있다.
핸들러 : 컨트롤러의 이름을 핸들러로 변경. 어댑터 때문에 여러가지를 처리 할 수 있다.
- 어댑터 도입
- 어댑터를 추가해서 프레임워크를 유연하고 확장성 있게 설계
