Client - Web Server - WAS - DB
-
Web server (정적 리소스 처리): HTML, 이미지 등을 처리하며 잘 죽지 않고 오류화면 HTML을 노출 시킬 수 있다.
-
WAS, Web Application Server (동적 리소스 처리): 업무 분담으로 과부하를 줄여주며 애플리케이션 로직을 실행시킨다.
Servlet
: 자바를 사용해 웹 페이지를 동적으로 생성하는 서버측 프로그램 혹은 사양
서블릿은 서버에서 처리해야 하는 수많은 업무 중 비즈니스 로직을 제외한 모든 일을 대신 수행해준다.
이는 싱글톤으로 관리되어 공유 변수에 주의하여야 하며 소스코드는 싱글 스레드 프로그래밍하듯 개발하면 된다.
서블릿은 요청/응답 정보를 편리하게 사용할 수 있도록 HttpServletRequest, HttpServletResponse를 사용한다.
HTTP 요청을 하면 WAS는 request, response 객체를 새로 만들어 서블릿 객체를 호출한다. 그럼 그때 개발자는 request 객체에서 HTTP 요청 정보를 꺼내 쓰고, response 객체에 HTTP 응답 정보를 입력하면 된다.
WAS는 response 내용으로 HTTP 응답 정보를 생성해 브라우저로 전달해준다.
Spring MVC
서블릿으로 개발할 때는 뷰를 위한 HTML 코드가 자바 코드와 섞여 복잡했다.
이를 해결하기 위해 JSP를 사용해 뷰를 생성하는 HTML 작업을 분리시켰고 중간중간 동적인 작업이 필요한 부분만 자바 코드를 적용시켰다.
하지만 이 또한 많은 자바 코드가 JSP에 노출되어 JSP가 너무 많은 역할을 떠맡게 된다.
그래서 비즈니스 로직과 뷰를 그리는 작업을 분리하기 위하여 MVC 패턴을 사용하게 되었다.
JSP, Java Server Pages
: HTML 코드에 자바 코드를 넣어 동적 웹 페이지를 생성하는 웹 어플리케이션 도구
MVC 패턴이란 JSP가 처리하던 것을 컨트롤러와 뷰 영역으로 나눈 것이다.
컨트롤러는 HTTP 요청을 받아 파라미터를 검증하고 비즈니스 로직을 수행한다. 그리고 뷰에 전달할 결과 데이터를 조회해 모델에 담는다.
모델은 뷰에 출력할 데이터를 담아둔다. 모델 덕분에 뷰는 화면을 렌더링하는 일에만 집중하면 된다.
뷰는 모델에 담긴 데이터를 사용해 화면을 그린다. (HTML 생성)
[Controller vs Service]
컨트롤러에 비즈니스 로직을 둘 수는 있지만, 이는 컨트롤러가 너무 많은 역할을 담당하게 된다.
그래서 비즈니스 로직을 Service 서비스 계층을 별도로 생성하여 처리한다.
그리고 Controller 컨트롤러는 비즈니스 로직이 있는 서비스를 호출하는 역할을 담당한다.비즈니스 로직을 변경하면 비즈니스 로직을 호출하는 컨트롤러의 코드도 함께 변경될 수 있다.
MVC 패턴 동작
Front Controller
초기 MVC 패턴은 컨트롤러의 역할과 뷰의 렌더링 역할을 명확히 구분하여 뷰의 코드가 깔끔하고 직관적이도록 해주었다. 하지만 컨트롤러는 중복이 많아 프론트 컨트롤러(Front Controller) 패턴을 도입하게 되었다.
프론트 컨트롤러는 프론트 컨트롤러라는 서블릿 하나로 클라이언트의 요청을 받은 다음 프론트 컨트롤러가 요청에 맞는 컨트롤러를 찾아 호출해주는 역할을 수행한다. (수문장같은 역할)
그래서 스프링에서는 DispatcherServlet이 FrontController 패턴으로 구현되어 있어 이를 사용할 수 있다.
Spring MVC 구조
스프링 MVC의 전체 구조를 보면 아래와 같다.
- DispatcherServlet(Front Controller)
: 제일 앞단에서 HTTP Request를 처리하는 컨트롤러 - Controller(Handler)
: HTTP Request를 처리해 Model을 만들고 View 지정 - ModelAndView
: Controller에 의해 반환된 Model과 View가 Wrapping 된 객체
(Model은 데이터만 저장하고 ModelAndView는 데이터와 이동하고자 하는 view page를 함께 저장한다.) - ViewResolver
: ModelAndView를 처리해 View 그리기
동작 순서
- 핸들러 조회
- 핸들러 어댑터 조회
- 핸들러 어댑터 실행
- 핸들러 실행
- ModelAndView 반환
- viewResolver 호출
- View 반환
- 뷰 렌더링
Controller의 @RequestMapping
@RequestMapping는 실무에서 99.9 퍼센트는 사용할 정도로 많이 쓰인다.
이는 요청 정보를 매핑하는 어노테이션으로 해당 URL이 호출되면 해당 메소드가 실행된다.
- @GetMapping
- @PostMapping
위와 같이 명확하게 나누어 쓰는 것을 추천한다.
@Controller vs @RestController
@Controller는 반환 값이 String일 때 뷰 이름으로 인식하여 뷰를 찾고 뷰가 랜더링 된다.
반면, @RestController는 반환 값으로 뷰를 찾는 것이 아닌, HTTP 메시지 바디에 바로 입력되어 반환된 문자열을 그대로 노출시킬 수 있다.
