프론트컨트롤러

Goal : 핸들러 매핑과 핸들러 어댑터가 어떻게 사용되는지 알아본다. 핸들러 매핑과 핸들러 어댑터 OldController hello/servlet/web/springmvc/old/OldController.java @Component("/springmvc/old-controller") public class OldController implements Controller { // @Component("/springmvc/old-controller")를 해주면 스프링빈의 이름이 /springmvc/old-controller가 된다 @Override public ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse respon..

Goal : 지금까지 v1~v5로 점진적으로 발전시킨 프레임워크를 정리해보자 ** 정리 v1 : 프론트 컨트롤러 도입 기존 구조를 최대한 유지하면서 프론트 컨트롤러를 도입 v2 : view 분류 단순 반복 되는 뷰 로직 분리 v3 : Model 추가 서블릿 종속성 제거 뷰 이름 중복 제거 v4 : 단순하고 실용적인 컨트롤러 v3와 거의 비슷 구현 입장에서 ModelView를 직접 생성해서 반환하지 않도록 편리한 인터페이스 제공 v5 : 유연한 컨트롤러 어댑터 도입 어댑터를 추가해서 프레임워크를 유연하고 확장성 있게 설계 스프링MVC 지금까지 작성한 코드는 스프링MVC 프레임워크의 핵심 코드의 축약 버전이며 구조도 거의 같다. @RequestMapping("/hello") RequestMappingHand..

Goal : 어댑터 패턴을 사용해서 프론트 컨트롤러가 다양한 방식의 컨트롤러를 처리할 수 있도록 변경해본다. 유연한 컨트롤러 2 FrontControllerServletV5 hello/servlet/web/frontcontroller/v5/frontControllerServletV5.java package hello.servlet.web.frontcontroller.v5; @WebServlet(name="frontControllerServletV5", urlPatterns = "/front-controller/v5/*") public class FrontControllerServletV5 extends HttpServlet { private void initHandlerMappingMap() { hand..

어댑터 패턴 개요 지금까지 우리가 개발한 프론트 컨트롤러는 한가지 방식의 컨트롤러 인터페이스만 사용할 수 있다. ControllerV3, ControllerV4는 완전히 다른 인터페이스다. 따라서 호환이 불가하므로 이럴 때 어댑터를 사용한다. public interface ControllerV3 { ModelView process(Map paramMap); } public interface ControllerV4 { String process(Map paramMap, Map model); } Goal : 어댑터 패턴을 사용해서 프론트 컨트롤러가 다양한 방식의 컨트롤러를 처리할 수 있도록 변경해본다. 유연한 컨트롤러 1 v5 구조 아키텍쳐 핸들러 어댑터 : 중간에 어댑터 역할을 하는 어댑터가 추가되었고 이..

실용적인 컨트롤러 개요 앞에서 만든 v3 컨트롤러는 서블릿 종속성을 제거하고 뷰 경로의 중복을 제거한 잘 설계된 컨트롤러 이지만 컨트롤러 인터페이스를 구현하는 개발자 입장에서는 항상 ModelView 객체를 생성하고 반환해야 하는 부분이 번거롭다. 좋은 프레임워크란 아키텍쳐도 중요하지만, 그와 더불어 개발자가 단순하고 편리하게 사용할 수 있어야 한다 ( = 실용성) Goal : v3를 변경해서 개발자가 편리하게 사용할 수 있도록 v4를 개발해보자 실용적인 컨트롤러 v4 구조 아키텍쳐 ControllerV4 hello/servlet/web/frontcontroller/v4/ControllerV4.java package hello.servlet.web.frontcontroller.v4; import java..

model 분리 개요 1. 서블릿 종속성 제거 컨트롤러 입장에서는 HttpServletRequest, HttpServletResponse가 꼭 필요할까? 요청 파라미터 정보는 자바의 Map으로 대신 넘기도록 하면 지금 구조에서는 컨트롤러가 서블릿 기술을 몰라도 동작할 수 있다. 그리고 request객체를 Model로 사용하는 대신에 별도의 Model 객체를 만들어서 반환하면 된다. 2. 뷰 이름 중복 제거 컨트롤러에서 지정하는 뷰 이름에 중복이 있음을 확인할 수 있다. 컨트롤러는 뷰의 논리 이름을 반환하고, 실제 물리 위치의 이름은 프론트 컨트롤러에서 처리하도록 단순화 한다. 이렇게 하면 후에 뷰의 폴더 위치가 함께 이동해도 프론트 컨트롤러만 수정하면 된다. ex) "/WEB-INF/views/-.jsp..

프론트 컨트롤러 패턴 소개 공통의 관심사를 별도로 모으는 소위 문지기 역할을 하는 것을 controller앞에 도입한다. 프론트 컨트롤러 패턴 특징 프론트 컨트롤러 서블릿 하나로 클라이언트의 요청을 받음 프론트 컨트롤러가 요청에 맞는 컨트롤러를 찾아서 호출 입구를 하나로 공통 처리 가능 프론트 컨트롤러를 제외한 나머지 컨트롤러는 서블릿을 사용하지 않아도 됨. 스프링 웹 MVC와 프론트 컨트롤러 스프링 웹MVC의 핵심도 바로 프론트컨트롤러이며 스프링 웹MVC의 DispatcherServlet이 프론트 컨트롤러 패턴으로 구현되어 있음 프론트 컨트롤러 도입 전 과 후의 아키텍쳐 Goal : 기존 코드를 최대한 유지하면서, 프론트 컨트롤러를 도입해본다. 먼저 구조를 맞추어두고 점진적으로 리팩토링을 한다. 프론트..