devlog

스프링 MVC 구조는 우리가 만든 MVC 프레임워크 구조와 매우 유사하다 스프링 MVC도 Dispatcher Servlet이라는 프론트 컨트롤러 패턴으로 구현되어 있다. HTTP요청이 오면 HttpServlet이 제공하는 service()가 호출된다. 스프링 MVC는 DispatcherServlet의 부모인 FrameworkServlet에세 service()를 오버라이드 해두었다. 그러면 FrameworkServlet.service()를 호출하면 DispacherServlet의 doDispatch()가 호출된다. 스프링 MVC의 동작 순서를 보자 핸들러 조회: 핸들러 매핑을 통해 요청 URL에 매핑된 핸들러를 조회한다. 핸들러 어댑터 조회: 조회한 핸들러에 맞는 어댑터를 조회한다. 핸들러 어댑터 실행 :..

간단한 회원가입 시스템을 처리하는 시스템을 MVC패턴으로 구현해 보자 위 그림은 구현해야 할 MVC프레임워크 구조도 이다. 전체적인 과정 HTTP요청이 들어오면 FrontController가 호출된다. 요청이 들어오면 FrontController는 핸들러 매핑 정보에서 Url을 통해 핸들러를 받은 후 핸들러의 타입을 얻기 위해 핸들러 어댑터 목록에서 핸들러 어댑터를 받은 후 핸들러 어댑터를 호출한다. 그리고 핸들러에서 비즈니스 로직을 한 후 modelView를 FrontController에 반환한다 그럼 FrontController는 ViewResolver를 통해 Url을 반환받은 후 MyView를 통해 클라이언트에게 HTML응답을 전송한다. 하나씩 알아 보자! 여기서 핸들러는 컨트롤러라고 보면 된다!...

서블릿으로 개발을 하면 View화면을 위한 HTML을 만드는 작업이 지저분하고 복잡했다 JSP를 사용하면 HTML을 깔끔하게 가져가고, 중간중간 동적으로 변경이 필요한 부분에 자바 코드를 사용할 수 있었다. 하지만 JSP역시 HTML과 자바 코드가 모두 JSP파일 안에 있다 JSP가 너무 많은 역할을 한다 그리고 View부분과 자바 코드 부분의 변경 라이프 사이클이 다르다 근데 View부분과 자바 코드가 한 파일에 있으면 View부분을 수정하려고 해도 자바 코드 부분을 봐야 하고 자바 부분을 수정하려 해도 View부분을 봐야 한다는 문제점이 생긴다 그래서 비즈니스 로직은 서블릿처럼 다른 곳에서 처리하고 JSP는 목적에 맞게 HTML화면을 그리는 일에 집중하도록 나누는 MVC패턴이 등장했다. M(모델) 뷰..

서블릿을 이용하는 방식과 JSP를 이용하는 방식을 비교해 보자 두 방식을 비교하기 위해 간단한 회원가입 save 기능을 구현한다. 클라이언트에서 유저의 이름과 나이를 전송한다. 서블릿이용 @WebServlet(name = "memberSaveServlet", urlPatterns = "/servlet/members/save") public class MemberSaveServlet extends HttpServlet { private MemberRepository memberRepository = MemberRepository.getInstance(); @Override protected void service(HttpServletRequest request, HttpServletResponse resp..

Http의 헤더 부분을 설정해 보자 메시지 타입 설정 response.setContentType("text/plain") 하면 보낼 메시지의 타입을 설정할 수 있다. response.setCharacterEncoding("utf-8") 인코딩 방식을 설정할 수 있다. 쿠키 설정 메서드 Cookie cookie = new Cookie("myCookie", "good") 쿠키 객체 생성 cookie.setMaxAge(600); 600초 동안 유지 response.addCookie(cookie) 쿠기 추가하기 redirect 메서드 response.sendRedirect("/basic/hello-form.html"); 현재 페이지가 호출되면 /basic/hello-form.html로 이동한다. HTTP응답 데..

HTTP 요청 메시지를 통해 클라이언트에서 서버로 데이터를 전달하는 3가지 방법이 있다. GET -퀴리 파라미터 /url?name=kim&sex=male 같은 형식으로 URL의 쿼리 파라미터에 데이터를 포함해서 전달한다. 메시지 바디 없이 전송한다. POST -HTML Form 메시지 바디에 쿼리 파라미터 형식으로 전달한다 content-type:application/x-www-form-urlencoded HTTP message body에 데이터 담아서 요청 HTTP API에서 주로 사용한다. 주로 JSON사용 GET 쿼리 파라미터 전달 데이터 username = kim, age = 20을 서버로 전송해 보자 메시지 바디 없이 URL의 쿼리 파라미터를 사용해서 데이터를 전달한다 쿼리 파라미터는 URL에 ..

스프링 부트 환경에서 서블릿을 등록하고 사용해 보자! 스프링 부트는 서블릿을 직접 등록해서 사용할 수 있도록 @ServletComponentScan을 지원한다. 이 애노테이션을 사용하면 서블릿을 자동 등록 해 준다. @ServletComponentScan @SpringBootApplication public class ServletApplication { public static void main(String[] args) { SpringApplication.run(ServletApplication.class, args); } } 서블릿을 등록해 보자 @WebServlet(name = "helloServlet", urlPatterns = "/hello") public class HelloServlet e..

서블릿 객체는 쓰레드가 호출하게 된다. 동시 요청이 오면 쓰레드 하나로는 지연이 될 수 있으므로 동시 처리가 필요하면 쓰레드를 추가로 생성한다. 하지만 요청 마다 쓰레드를 생성하면 쓰레드 생성 비용이 비싸기 때문에 응답 속도가 늦어질 수 있다. 그리고 쓰레드 생성에 제한이 없기 때문에 너무 많은 쓰레드가 생성되면 서버가 죽을 수 있다. 그래서 보통의 WAS들은 쓰레드 풀을 이용해서 쓰레드를 이용한다. 쓰레드 풀에 미리 쓰레드를 일정 개수 생성을 해 두고 요청이 올 때마다 연결이 되어있지 않은 쓰레드에 연결을 해서 처리를 해 주고 사용 후 쓰레드 풀에 다시 반납한다. 쓰레드 풀에 모든 쓰레드가 연결되어있으면 쓰레드 대기를 하거나 거절을 한다. 이 방식을 사용하면 미리 쓰레드가 생성되어 있으므로 쓰레드를 생..

웹 서버 HTTP 기반으로 동작한다. 정적 리소스를 제공한다 (HTML, CSS, JS 이미지 영상) 예) NGINX, APACHE 웹 애플리케이션 서버(WAS) HTTP 기반으로 동작한다. 프로그램 코드를 실행해서 애플리케이션으로 로직을 수행한다. 예) 톰캣, Jetty, Undertow WAS는 정적 리소스, 애플리케이션 로직 모두 제공가능해서 WAS, DB만으로 시스템 구성이 가능하다. 하지만 WAS만으로 너무 많은 역할을 담당하면 서버가 과부하가 생길 수 있다. 그래서 웹 서버는 정적 리소스를 처리하고 동적 처리가 필요하면 WAS에 요청을 한다. 이러면 효율적인 리소스관리가 쉽다 정적 리소스가 많으면 Web서버 증설 애플리케이션 리소스가 많으면 WAS증설 서블릿 서블릿은 자바클래스의 일종으로 개발..

웹 스코프는 웹 환경에서만 동작한다 그중 request 웹 스코프에 대해 알아보자. Request 웹스코프는 HTTP 요청 하나가 들어오고 나갈 때까지 유지되는 스코프이며 각각의 HTTP 요청마다 별도의 빈 인스턴스가 생성되고 관리된다. 다음 그림을 보자 클라이언트 A와B는 싱글톤인 Controller와 Service빈을 공통으로 가지고 request scope빈은 개별로 다른 인스턴스를 HTTP 요청을 할 시에 할당되어 가진다. request빈의 특징은 HTTP가 들어오고 나갈 때까지 유지되는 것이기 때문에 클라이언트 A가 Controller에서 request scope빈을 요청하고 그 후 Service에서 resquest scope빈을 요청을 또 하더라도 같은 인스턴스의 전용 request scope..