Spring MVC 구조 및 처리 순서

오늘부터 토이 프로젝트를 만들기위해 MVC구조를 다시한번 공부하였다. 

 

 

1. Model(모델)

 

어플리케이션의 데이터이며, 모든 데이터 정보를 가공하여 가지고 있는 컴포넌트이다.

• 사용자가 이용하려는 모든 데이터를 가지고 있어야하며, View(뷰) 또는 Controller(컨트롤러)에 대해 어떤 정보도 알 수 없어야 한다.
• 변경이 일어나면 처리 방법을 구현해야 한다.

 

 

2. View(뷰)

 

시각적인 UI 요소를 지칭하는 용어이다.

• Model(모델)이 가지고 있는 데이터를 저장하면 안된다.
• Model(모델)이나 Controller(컨트롤러)에 대한 정보를 알면 안되며 단순히 표시해주는 역할을 가지고 있다.
• 변경이 일어나면 처리 방법을 구현해야 한다.

 

 

3. Controller(컨트롤러)

 

Model(모델)과 View(뷰)를 연결해주는 역할을 한다.

• Model(모델) 또는 View(뷰)에 대한 정보를 알아야 한다.
• Model(모델) 또는 View(뷰)의 변경을 인지하여 대처를 해야한다.

 

 

 

MVC의 처리 순서

1. 클라이언트가 서버에 요청을 하면, front controller인 DispatcherServlet 클래스가 요청을 받는다.
2. DispatcherServlet는 프로젝트 파일 내의 servlet-context.xml 파일의 @Controller 인자를 통해 등록한 요청 위임 컨트롤러를 찾아 매핑(mapping)된 컨트롤러가 존재하면 @RequestMapping을 통해 요청을 처리할 메소드로 이동한다.
3. 컨트롤러는 해당 요청을 처리할 Service(서비스)를 받아 비즈니스로직을 서비스에게 위임한다.
4. Service(서비스)는 요청에 필요한 작업을 수행하고, 요청에 대해 DB에 접근해야한다면 DAO에 요청하여 처리를 위임한다.
5. DAO는 DB정보를 DTO를 통해 받아 서비스에게 전달한다.
6. 서비스는 전달받은 데이터를 컨트롤러에게 전달한다.
7. 컨트롤러는 Model(모델) 객체에게 요청에 맞는 View(뷰) 정보를 담아 DispatcherServlet에게 전송한다.
8. DispatcherServlet는 ViewResolver에게 전달받은 View정보를 전달한다.
9. ViewResolver는 응답할 View에 대한 JSP를 찾아 DispatcherServlet에게 전달한다.
10. DispatcherServlet는 응답할 뷰의 Render를 지시하고 뷰는 로직을 처리한다.
11. DispatcherServlet는 클라이언트에게 Rendering된 뷰를 응답하며 요청을 마친다.

 

 

 

---

 

 

 

Spring MVC 처리 순서

1. 클라이언트(Client)가 서버에 어떤 요청(Request)을 한다면 스프링에서 제공하는 DispatcherServlet 이라는 클래스(일종의 front controller)가 요청을 가로챈다.

(web.xml에 살펴보면 모든 url ( / )에 서블릿 매핑을하여 모든 요청을 DispatcherServlet이 가로채게 해둠(변경 가능))

 

2. 요청을 가로챈 DispatcherServlet은 HandlerMapping(URL 분석등..)에게 어떤 컨트롤러에게 요청을 위임하면 좋을지 물어본다.

(HandlerMapping은 servlet-context.xml에서 @Controller로 등록한 것들을 스캔해서 찾아놨기 때문에 어느 컨트롤러에게 요청을 위임해야할지 알고 있다.)

 

3. 요청에 매핑된 컨트롤러가 있다면 @RequestMapping을 통하여 요청을 처리할 메서드에 도달한다.

 

4. 컨트롤러에서는 해당 요청을 처리할 Service를 주입(DI)받아 비즈니스로직을 Service에게 위임한다.

 

5. Service에서는 요청에 필요한 작업 대부분(코딩)을 담당하며 데이터베이스에 접근이 필요하면 DAO를 주입받아 DB처리는 DAO에게 위임한다.

 

6. DAO는 mybatis(또는 hibernate등) 설정을 이용해서 SQL 쿼리를 날려 DB에 저장되어있는 정보를 받아 서비스에게 다시 돌려준다.

(이 때, 보통 Request와 함께 날아온 DTO 객체(@RequestParam, @RequestBody, ...)로 부터 DB 조회에 필요한 데이터를 받아와 쿼리를 만들어 보내고, 결과로 받은 Entity 객체를 가지고 Response에 필요한 DTO객체로 변환한다.)

 

7. 모든 비즈니스 로직을 끝낸 서비스가 결과물을 컨트롤러에게 넘긴다.

 

8. 결과물을 받은 컨트롤러는 필요에 따라 Model객체에 결과물 넣거나, 어떤 view(jsp)파일을 보여줄 것인지등의 정보를 담아 DispatcherServlet에게 보낸다.

 

9. DispatcherServlet은 ViewResolver에게 받은 뷰의 대한 정보를 넘긴다.

 

10. ViewResolver는 해당 JSP를 찾아서(응답할 View를 찾음) DispatcherServlet에게 알려준다.

(servlet-context.xml에서 suffix, prefix를 통해 /WEB-INF/views/index.jsp 이렇게 만들어주는 것도 ViewResolver)

 

11. DispatcherServlet은 응답할 View에게 Render를 지시하고 View는 응답 로직을 처리한다.

 

12. 결과적으로 DispatcherServlet이 클라이언트에게 렌더링된 View를 응답한다.

출처: https://jeong-pro.tistory.com/96

Spring MVC 구조의 처리 과정을 설명해보시오. (MVC process)

 

참고 iri-kang.tistory.com/4

Spring MVC 구조의 이해 및 처리과정