WebMaster

application.properties 에 ViewResolver 설정 추가 spring.mvc.view.prefix=/WEB-INF/views/ spring.mvc.view.suffix=.jsp 스프링 부트는 InternalResourceViewResolver라는 뷰 리졸버를 자동으로 등록하는데, 이때 application.properties 에 등록한 spring.mvc.view.prefix , spring.mvc.view.suffix 설정 정보를 사용해서 등록한다. 스프링 부트가 자동 등록하는 뷰 리졸버(실제로는 더 많지만, 중요한 부분 위주로 설명하기 위해 일부 생략) BeanNameViewResolver : 빈 이름으로 뷰를 찾아서 반환한다. (예: 엑셀 파일 생성 기능에 사용) Interna..

Controller 인터페이스 과거 버전 스프링 컨트롤러 org.springframework.web.servlet.mvc.Controller @Component : 이 컨트롤러는 /springmvc/old-controller라는 이름의 스프링 빈으로 등록되었다 빈의 이름으로 URL을 매핑할 것이다 이 컨트롤러가 호출되려면 다음 2가지가 필요하다. HandlerMapping(핸들러 매핑) 핸들러 매핑에서 이 컨트롤러를 찾을 수 있어야 한다. 예) 스프링 빈의 이름으로 핸들러를 찾을 수 있는 핸들러 매핑이 필요하다. HandlerAdapter(핸들러 어댑터) 핸들러 매핑을 통해서 찾은 핸들러를 실행할 수 있는 핸들러 어댑터가 필요하다. 예) Controller 인터페이스를 실행할 수 있는 핸들러 어댑터를 찾..

직접 만든 프레임워크 스프링 MVC 비교 FrontController -> DispatcherServlet handlerMappingMap -> HandlerMapping MyHandlerAdapter -> HandlerAdapter ModelView -> ModelAndView viewResolver -> ViewResolver MyView -> View 동작 순서 핸들러 조회: 핸들러 매핑을 통해 요청 URL에 매핑된 핸들러(컨트롤러)를 조회한다. 핸들러 어댑터 조회: 핸들러를 실행할 수 있는 핸들러 어댑터를 조회한다. 핸들러 어댑터 실행: 핸들러 어댑터를 실행한다. 핸들러 실행: 핸들러 어댑터가 실제 핸들러를 실행한다. ModelAndView 반환: 핸들러 어댑터는 핸들러가 반환하는 정보를 Mode..

만약 어떤 개발자는 ControllerV3 방식으로 개발하고 싶고, 어떤 개발자는 ControllerV4 방식으로 개발하고 싶다면 어떻게 해야 할까? 현재는 인터페이스 타입이 고정이 되어 있기 때문에 원하는 방식이 선택이 안된다. 어댑터 패턴 지금까지 우리가 개발한 프론트 컨트롤러는 한 가지 방식의 컨트롤러 인터페이스만 사용할 수 있다. ControllerV3 , ControllerV4는 완전히 다른 인터페이스이다. 따라서 호환이 불가능하다. 마치 v3는 110v이고, v4는 220v 전기 콘센트 같은 것이다. 이럴 때 사용하는 것이 바로 어댑터이다. 어댑터 패턴을 사용해서 프론트 컨트롤러가 다양한 방식의 컨트롤러를 처리할 수 있도록 변경해보자 핸들러 어댑터: 중간에 어댑터 역할을 하는 어댑터가 추가되었..

앞서 만든 v3 컨트롤러는 서블릿 종속성을 제거하고 뷰 경로의 중복을 제거하는 등, 잘 설계된 컨트롤러이다. 그런데 실제 컨트 톨러 인터페이스를 구현하는 개발자 입장에서 보면, 항상 ModelView 객체를 생성하고 반환해야 하는 부분이 조금은 번거롭다. 좋은 프레임워크는 아키텍처도 중요하지만, 그와 더불어 실제 개발하는 개발자가 단순하고 편리하게 사용할 수 있어야 한다. 소위 실용성이 있어야 한다. interface 작성 각 Controller들이 구현해야 하는 인터페이스 작성 Model을 파라미터로 입력받아 model을 채워준다. ViewName(논리적 이름)만 반환하도록 인터페이스를 작성 복잡하게 ModelView 클레스를 만들지 않고 사용이 가능하다 Controller 작성 클라이 언트 입장(Co..

서블릿 종속성 제거 컨트롤러 입장에서 HttpServletRequest, HttpServletResponse이 꼭 필요할까? 요청 파라미터 정보는 자바의 Map으로 대신 넘기도록 하면 지금 구조에서는 컨트롤러가 서블릿 기술을 몰라도 동작할 수 있다. 그리고 request 객체를 Model로 사용하는 대신에 별도의 Model 객체를 만들어서 반환하면 된다. 우리가 구현하는 컨트롤러가 서블릿 기술을 전혀 사용하지 않도록 변경해보자. 이렇게 하면 구현 코드도 매우 단순해지고, 테스트 코드 작성이 쉽다. 뷰 이름 중복 제거 컨트롤러에서 지정하는 뷰 이름에 중복이 있는 것을 확인할 수 있다. 컨트롤러는 뷰의 논리 이름을 반환하고, 실제 물리 위치의 이름은 프론트 컨트롤러에서 처리하도록 단순화 하자. 이렇게 해두면..

컨트롤러가 더 이상 View에 대한 코드를 고민하지 않아도 된다. Interface 작성 각 Controller들이 구현해야 하는 인터페이스 작성 MyView 작성 Controller 작성 MemberFormController 이제 각 컨트롤러는 복잡한 dispatcher.forward()를 직접 생성해서 호출하지 않아도 된다. 단순히 MyView 객체를 생성하고 거기에 뷰 이름만 넣고 반환하면 된다. ControllerV1 을 구현한 클래스와 ControllerV2를 구현한 클래스를 비교해보면, 이 부분의 중복이 확실하게 제거된 것을 확인할 수 있다 FrontControllerV2 작성 ControllerV2의 반환 타입이 MyView 이므로 프론트 컨트롤러는 컨트롤러의 호출 결과로 MyView를 반환..

interface 작성 서블릿과 비슷한 모양의 컨트롤러 인터페이스를 도입한다. 각 컨트롤러들은 이 인터페이스를 구현하면 된다. 프론트 컨트롤러는 이 인터페이스를 호출해서 구현과 관계없이 로직의 일관성을 가져갈 수 있다. 이제 이 인터페이스를 구현한 컨트롤러를 만들어보자. 지금 단계에서는 기존 로직을 최대한 유지하는게 핵심이다 Controller 작성 내부 로직은 기존 서블릿과 거의 같다 리펙토링의 할 때에는, 변경해야할 관심사만 변경해야 한다(같은 레벨만 변경해야 한다) FrontControllerV1 작성 urlPatterns urlPatterns = "/front-controller/v1/*" : /front-controller/v1 을 포함한 하위 모든 요청은 이 서블릿에서 받아들인다. contro..

프론트 컨트롤러 패턴 적용 전 프론트 컨트롤러 패턴 적용 후 FrontController 패턴 특징 프론트 컨트롤러 서블릿 하나로 클라이언트의 요청을 받음 프론트 컨트롤러가 요청에 맞는 컨트롤러를 찾아서 호출 입구를 하나로! 공통 처리 가능 프론트 컨트롤러를 제외한 나머지 컨트롤러는 서블릿을 사용하지 않아도 됨 스프링 웹 MVC와 프론트 컨트롤러 스프링 웹 MVC의 핵심도 바로 FrontController 스프링 웹 MVC의 DispatcherServlet이 FrontController 패턴으로 구현되어 있음

MVC 패턴을 적용한 덕분에 컨트롤러의 역할과 뷰를 렌더링 하는 역할을 명확하게 구분할 수 있다. 특히 뷰는 화면을 그리는 역할에 충실한 덕분에, 코드가 깔끔하고 직관적이다. 단순하게 모델에서 필요한 데이터를 꺼내고, 화면을 만들면 된다. 그런데 컨트롤러는 딱 봐도 중복이 많고, 필요하지 않은 코드들도 많이 보인다. MVC 컨트롤러의 단점 포워드 중복 View로 이동하는 코드가 항상 중복 호출되어야 한다. 물론 이 부분을 메서드로 공통화해도 되지만, 해당 메서드도 항상 직접 호출해야 한다. ViewPath에 중복 prefix: /WEB-INF/views/ ,suffix: .jsp 그리고 만약 jsp가 아닌 thymeleaf 같은 다른 뷰로 변경한다면 전체 코드를 다 변경해야 한다 사용하지 않는 코드 다음..