🪴 Spring MVC
🟦 기존 문제
-
하나의 서블릿 or JSP를 통해 비즈니스 로직과 뷰 렌더링을 모두 처리
➡️ 역할이 과중됨
➡️ 유지보수의 어려움
UI를 변경하기 위해서 비즈니스 로직이 함께있는 파일을 수정해야 함 비즈니스 로직을 변경하기 위해서 HTML 코드가 함께있는 파일을 수정해야 함 -
비즈니스 로직과 UI의 변경 라이프 사이클이 다름 (변경 주기가 다르면 분리!)
UI를 수정하는 일과 비즈니스 로직을 수정하는 일은 각각 다르게 발생할 가능성이 높음
UI를 수정하는 일과 비즈니스 로직을 수정하는 일은 대체로 서로에게 영향을 주지 않음
➡️ 유지보수의 어려움
-
JSP와 같은 뷰 템플릿은 화면을 렌더링하는 기능에 특화되어있음
특화되어 있는 기능의 업무만 담당하는 것이 가장 효과적
🟦 Model View Controller (Service)
-
Model
- 뷰에 출력할 데이터를 담아둠.
- 뷰가 필요한 데이터를 모두 모델에 담아서 전달해주기에 뷰는 비즈니스 로직이나 데이터 접근을 몰라도됨.
- 화면 렌더링하는 역할에 집중
-
View
- 모델에 담겨있는 데이터를 사용해서 화면을 그리는 일에 집중
-
Controller
- HTTP 요청을 받아 파라미터를 검증
- 비즈니스 로직 실행
- 뷰에 전달할 결과 데이터를 조회해서 모델에 담음
-
Service
컨트롤러에 비즈니스 로직을 둘 수 있지만 컨트롤러에 역할이 과중되는 것을 막기위해
서비스라는 별도의 계층을 만들어 비즈니스 로직을 처리하도록 한다.컨트롤러는 비즈니스 로직이 있는 서비스를 호출
🟦 MVC 패턴
HTTP Requset를 처리하는 부분인 Controller
데이터를 처리해 정제된 데이터를 넣는 Model
정제된 데이터를 활용해 사용자에게 보여주는 View
➡️ UI와 도메인 분리
역할을 분리하여 유연하고 확장성 있게 애플리케이션을 설계할 수 있도록 한 디자인 패턴
🟦 MVC 패턴 한계
Controller에 중복된 코드와 필요하지 않은 코드들이 많음
-
포워드 중복
View로 이동하는 코드가 항상 중복 호출 -
viewPath 일부 중복
String = viewPath = "/WEB-INF/.../...jsp"; 에서
prefix(/WEB-INF/.../), suffix(.jsp) 중복다른 뷰로 변경(jsp -> thymeleaf) or 폴더 변경 or 확장자 변경
➡️ 전체 코드 변경해야 함 -
사용하지 않는 코드
HttpServletRequest, HttpServletResponse response
-> 사용하는 경우도 있고 사용하지 않는 경우도 있음
-> 사용하는 코드는 TC 작성 어려움
➡️ 공통 처리 어려움
기능 복잡 -> 컨트롤러에서 공통으로 처리해야하는 부분 증가
(공통 기능을 메서드로 뽑아낸다 해도 해당 메서드를 항상 호출해야하므로 중복 해소 X)
컨트롤러 호출 전에 공통 기능을 처리하여 문제 해결 가능 ➡️ Front Controller Pattern
- /WEB-INF
WEB-INF 하위 경로에 있는 파일에는 외부에서 직접 접근 불가능
-> 브라우저에서 직접 접근 불가
-> 오직 서버 내에서만 접근 가능
View의 경우 Controller를 통해 호출- redirect <-> forward
redirect
실제 클라이언트(웹브라우저)에 응답이나갔다가 클라이언트가 redirect 경로로 다시 요청
-> 클라이언트 인지 가능, URL 경로 변경됨
forward
서버 내부에서 일어나는 호출
-> 클라이언트는 인지 불가능인프런 스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술 (김영한) 참조
