Spring MVC 패턴

 

옛날 옛적에...

MVC 패턴 이전에는 하나의 서블릿과 JSP만으로 비즈니스 로직과 뷰 로직을 모두 처리하였다.

이렇게 하게 되면, 한 서블릿이나 JSP이 너무 많은 역할을 담당하게 되고, 이는 곧 유지보수의 어려움으로 이어진다.

따라서, MVC 패턴이라는 것을 만들었다.

 

MVC 패턴 등장

MVC 패턴은 하나의 서블릿이나, JSP로 처리하던 것을 컨트롤러(Controller)와 뷰(View)라는 영역으로 서로 역할을 나눈 것을 말한다.

 

• 컨트롤러(Controller) : HTTP 요청을 받아서 파라미터를 검증하고, 비즈니스 로직을 실행한다. 그리고 뷰에 전달한 결과 데이터를 조회해서 모델에 담는다.
• 모델 : 뷰에 출력할 데이터를 담아둔다. 
• 뷰 : 모델에 담겨있는 데이터를 이용해 화면을 그린다.

뷰는 모델이 필요한 데이터를 모두 가지고 있기 때문에, 비즈니스 로직이나 데이터 접근을 몰라도 된다. -> 역할의 분리

 

컨트롤러의 역할이 좀 많네

 

컨트롤러(Controller)에 비즈니스 로직을 둘 수 있지만, 이렇게 하게 되면 컨트롤러가 너무 많은 역할을 담당하게 된다.

따라서, 비즈니스 로직은 서비스(Service)라는 계층을 별도로 만들어서 처리하고, 컨트롤러는 서비스를 호출하는 역할을 담당한다.

 

 

하지만, 개발을 하다보면 컨트롤러(Controller)는 계속 생기게 되고 컨트롤러들끼리 겹치는 부분이 점점 많아지게 된다.

따라서, 공통된 로직을 한번에 처리하기 위해 프론트 컨트롤러 패턴을 도입한다.

 

=> 프론트 컨트롤러는 스프링 웹 MVC의 DispatcherServlet이다.

이렇게 함으로써, 개발자는 프론트 컨트롤러를 제외한 나머지 컨트롤러는 서블릿을 사용하지 않아도 된다.

 

또, 서로 다른 인터페이스 즉 이미 정의된 핸들러를 변경하지 않고 기존에 사용하던 대로 사용하기 위해 어댑터 패턴을 

사용한다.

 

최종적으로, 아래와 같은 구조가 나온다.

 

동작 순서

 

1. 핸들러 조회 : 핸들러 매핑을 통해 요청 URL에 매핑된 핸들러(컨트롤러)를 조회한다.
2. 핸들러 어댑터 조회 : 핸들러를 실행할 수 있는 핸들러 어댑터를 조회한다.
3. 핸들러 어댑터 실행 : 핸들러 어댑터를 실행한다.
4. 핸들러 실행 : 핸들러 어댑터가 실제 핸들러를 실행한다.
5. ModelAndView 반환 : 핸들러 어댑터는 핸들러가 반환하는 정보를 ModelAndView로 변환해서 반환한다.
6. viewResolver 호출 : 뷰 리졸버를 찾고 실행한다.
7. View 반환 : 뷰 리졸버는 뷰의 논리 이름을 물리 이름으로 바꾸고, 렌더링 역할을 담당하는 뷰 객체를 반환한다.
8. 뷰 렌더링 : 뷰를 통해서 뷰를 렌더링 한다.

 

그리고, MVC에서 역할 분배는 크게 3가지로 나눌 수 있다.

 

핸들러 매핑 : 아래의 방식으로 핸들러(컨트롤러)와 매핑되있다.  

• @RequestMapping 이 붙여져 있는 것
• 스프링 빈의 이름으로 등록된 것

핸들러 어댑터 :  기존의 핸들러를 사용할 수 있도록 중간 다리 역할을 한다.

• @RequestMapping 이 붙여져 있는 것
• HttpRequestHandler 처리
• Controller 인터페이스

뷰 리졸버 : View를 조회할 수 있게 도와준다.

• 빈 이름으로 뷰를 찾아서 반환한다.
• JSP 또는 타임리프를 처리할 수 있는 뷰를 반환한다.
  • ThymeleafViewResolver 스프링 부트에서 라이브러리만 추가하면 자동으로 등록해준다

 

 

위글은 김영한님의 스프링 MVC 1편 강의를 듣고 정리한 내용입니다!

 

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-mvc-1/dashboard

스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술 - 인프런 | 강의