서블릿

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..

MVC 패턴의 개요 너무 많은 역할 : 하나의 서블릿이나 JSP만으로 비지니스 로직과 뷰 렌더링까지 모두 처리하게 되면 유지보수가 어려워진다. 변경의 라이프 사이클 : UI와 비지니스 로직을 수정하는 일은 다르게 발생하고 서로에게 영향을 주지 않으므로 유지보수에 부적합 기능 특화 : 특히 JSP와 같은 뷰 템플릿 화면은 렌더링하는데 최적화 ModelViewController MVC 패턴이란 하나의 서블릿이나 JSP로 처리하던 것을 컨트롤러(Controller)와 뷰(View)라는 영역으로 역할을 나누는 것을 의미한다. 구분 역할 컨트롤러 HTTP 요청을 받아 파라미터를 검증하고 비지니스로직을 호출한다. 그리고 뷰에 전달할 결과 데이터를 조회하여 모델에 담는다 모델 뷰에 출력할 데이터를 담아둔다. 뷰가 필..

JSP로 회원 관리 웹 어플리케이션을 만들어 보자 JSP 라이브러리 추가 dependencies { implementation 'org.springframework.boot:spring-boot-starter-web' //JSP 추가 시작 implementation 'org.apache.tomcat.embed:tomcat-embed-jasper:' implementation 'javax.servlet:jstl:1.2' //JSP 추가 끝 compileOnly 'org.projectlombok:lombok' annotationProcessor 'org.projectlombok:lombok' testImplementation 'org.springframework.boot:spring-boot-starter-..

회원 관리 웹 어플리케이션 요구사항 회원정보 이름 : username 나이 : age 기능 요구사항 회원 저장 회원 목록 조회 본격적으로 서블릿으로 회원 관리 웹 어플리케이션을 만들어 보자 회원 도메인 모델 package hello.servlet.domain.member; import lombok.Getter; import lombok.Setter; @Getter @Setter public class Member { private Long id; private String username; private int age; Member(){ } public Member(String username, int age){ this.username = username; this.age = age; } } 위의 패키..

HTTP 응답 메세지는 주로 다음 내용을 담아서 전달한다 단순 텍스트 응답 writer.println("ok"); HTML 응답 HTTP API - MessageBody JSON 응답 HTML 응답 @WebServlet(name="responseHtmlServlet", urlPatterns = "/response-html") public class ResponseHtmlServlet extends HttpServlet { @Override protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { //Content-Type: text/html; cha..

HttpServletResponse 역할 HTTP 응답 메세지를 생성한다 HTTP 응답코드 지정 헤더 생성 바디 생성 편의기능 제공 Content-Type, 쿠키, Redirect 직접 헤더 정보 출력해보기 @WebServlet(name="responseHeaderServlet", urlPatterns = "/response-header") public class ResponseHeaderServlet extends HttpServlet { @Override protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { //[status-line] res..