Most Muscular Most Muscular

클라이언트의 요청 메시지에서 @RequestParam 어노테이션으로 파라미터를 받아 사용할 수 있다 Spring을 사용하면 해당 어노테이션을 더 효율적으로 사용할 수 있다 1. HttpServletRequest 사용 HttpServletRequest 객체에서 직접 파라미터를 받아오는 방식이다 2. @RequestParam 사용 핸들러 파라미터에 @RequestParam 어노테이션을 추가하면 메시지를 받고 받은 메시지에서 객체로 받아오는 과정을 생략할 수 있다 3. 파라미터 이름 맞추기 @RequestParam 어노테이션에서 받아오는 파라미터명과 핸들러의 파라미터명을 일치시키면 어노테이션 파라미터를 생략할 수 있다 4. 어노테이션 생략하기 위 조건을 모두 만족시키고 String, int 등의 단순 타입이라..

컨트롤러의 메소드에 @ReqeustMapping 어노테이션을 추가하면 클라이언트의 요청을 수행할 수 있다 또한 추가적으로 @RequestMapping 어노테이션에 파라미터를 추가하면 요청을 선택적으로 수행할 수 있다 이번엔 요청 매핑에 관련된 설정 정보들을 알아 볼 것이다 @RestController 일반적인 @Controller가 반환하는 String값은 뷰로 인식되어 렌더링 과정을 거친다. 하지만 @RestController가 반환하는 String 값은 렌더링 과정 없이 HTTP Body에 그대로 들어간다. 어노테이션의 Rest는 Rest API의 Rest를 의미하며 Json을 return 할 수 있도록 설계된 것이다 @RequestMapping("/hello-basic", "hello-koji") ..

앞서 보았듯이 가장 가장 우선순위가 높은 핸들러 매핑과 핸들러 어댑터는 각각 RequestMappingHandlerMapping, RequestMappingHandlerAdapter 이다 이제 이 어노테이션 기반의 스프링 MVC 컨트롤러를 만들어 볼 것이다 1. 컨트롤러 작성 더보기 클래스 레벨에서 @Controller, @RequestMapping 어노테이션이 있다면 Spring은 해당 클래스를 핸들러로 인식하고 핸들러 리스트에 추가한다. @RequestMapping 어노테이션만 존재한다면 컴포넌트 스캔의 대상이 되지 않으므로 @Controller를 사용했다 2. 컨트롤러 통합 더보기 @RequestMapping 어노테이션은 메서드 단위로 동작하므로 각 컨트롤러들을 하나로 통합해 보았다 3. 편의성 수..

Spring MVC 전체 구조 이전 포스팅에서 직접 MVC 프레임워크를 만들어 보았다. Spring MVC 프레임워크와 직접 만든 프레임워크를 비교해보자 FrontController : DispatcherServlet ModelView : ModelAndView MyView : View Spring MVC 동작 과정 1. 핸들러 조회 더보기 스프링은 다음의 순서로 핸들러를 탐색하고 먼저 탐색된 핸들러를 사용한다 (정확히는 모든 핸들러를 찾은 뒤 다음의 순서로 정렬한 뒤 하나씩 검사하는 것이다) 1. RequestMappingHandlerMapping 탐색 Annotation 기반의 컨트롤러인 @RequestMapping 핸들러를 탐색한다 2. BeanNameHandlerMapping 탐색 스프링 빈의 이..

1. 프론트 컨트롤러 도입하기 기존의 방식에서는 여러개의 서블릿을 통해 각각의 컨트롤러가 호출되었다. 이제는 하나의 서블릿에서 요청을 받고 요청에 맞는 컨트롤러를 찾아 호출하는 프론트 컨트롤러 패턴을 구현해 보자 이를 구조적으로 표현하면 다음과 같다 직접 구현하면 다음과 같다 1. URL 매핑 정보에서 컨트롤러 조회 + 2. 컨트롤러 호출 3. 컨트롤러에서 JSP forward 2. View 분리하기 만들어보니 각 컨트롤러에서 View로 forward하는 과정이 중복되고 컨트롤러에서 forward하는 불필요한 책임이 있다. MyView라는 클래스를 만들어 책임을 분리할 필요가 있다 이를 구현하면 다음과 같다 1. URL 매핑 정보에서 컨트롤러 조회 2. 컨트롤러 호출 3. MyView 반환 4. JSP ..

MVC 패턴의 등장 이유 너무 많은 역할 하나의 서블릿이나 JSP만으로 비즈니스 로직과 뷰 렌더링까지 모두 처리하게 되면, 너무 많은 역할을 하게 되고, 결과적으로 유지보수가 어려워진다. 비즈니스 로직을 호출하는 부분에 변경이 발생해도 해당 코드를 손대야 하고, UI를 변경할 일이 있어도 해당 코드를 손대야 한다. HTML 코드 한줄을 수정해야 하는데 수백줄의 자바 코드가 있다고 상상해보라! 또는 비즈니스 로직을 하나 수정해야 하는데 수백 수천줄의 HTML 코드가 함께 있다고 상상해보라! 변경의 라이프 사이클 위에서 말한 것과 거의 비슷한 이유다. 비즈니스 로직과 UI는 변경의 라이프 사이클이 다를 확률이 높다. 변경의 라이프 사이클이 다른 부분을 하나의 코드로 관리하는 것은 유지보수하기에 좋지 않다 기..

웹 어플리케이션 설계 회원 정보 이름: username 나이: age 기능 요구사항 회원 저장 회원 목록 조회 서블릿으로 웹 어플리케이션 설계하기 1. 멤버 생성 폼 2. 멤버 리스트 JSP로 웹 어플리케이션 설계하기 1. 멤버 생성 폼 2. 멤버 리스트 서블릿, JSP의 한계 서블릿의 사용 서블릿으로 개발할 때는 View 화면을 위한 HTML을 만드는 작업이 자바 코드에 섞여 지저분하고 복잡했다 이는 JSP로 넘어오면서 어느 정도 해결되었지만 아직 해결되지 않는 몇가지 고민이 남는다 JSP의 사용 JSP를 사용한 덕분에 View를 생성하는 작업을 깔끔하게 가져가고, 중간중간 동적으로 변경이 필요한 부분만 자바 코드를 적용했다 하지만 이렇게 해도 JSP의 책임이 너무 크다는 문제가 발생한다 위 예시를 보..

HttpServletResponse란? 서블릿이 생성한 응답 객체, 웹 어플리케이션 서버는 이 객체의 정보를 바탕으로 HTTP 응답 메시지를 생성하여 웹 브라우저에 전달한다 HttpServletResponse 사용법 1. writer.println() 사용 - 단순 텍스트를 전달할 경우 setContentType("text/plain") - HTML 텍스트를 전달할 경우 setContentType("text/html") 2. objectMapper.writeValueAsString() 사용 - 자바 객체에서 JSON 텍스트로 변환한 뒤 response.getWriter().write() 메소드를 사용 HTTP 응답 데이터 예시 - 단순 텍스트, HTML 1. 응답 데이터 - 단순 텍스트 2. 응답 데이터..