[Spring] MVC 패턴의 개요 - JSP는 만능이지만 만능이 아님

JSP 코드의 한계

JSP 코드의 구조

사실 JSP로 모든 비즈니스 로직과 뷰 로직을 해결할 수 있는 건 맞다.

하지만 이전 포스팅에서 말했다시피, JSP에 비즈니스 로직과 뷰 로직을 함께 두게 되면 JSP코드에 대한 부담이 커지게 되고, 비즈니스 로직 수정이나 뷰 로직 수정시 모든 코드를 확인 해야한다는 미친 단점이 존재한다. 

[Spring] 회원 관리 웹 애플리케이션 JSP 리팩토링

---

변경 주기 분리하기

비즈니스 로직 (자바 코드) 와 뷰 (HTML) 코드는 서로 라이프 사이클이 다르다.

즉, UI를 수정하는 일과 비즈니스 로직을 수정하는 일은 완전 독립적으로 수행할 확률이 높기 때문에, 서로 영향을 주지 않을 가능성이 크다.

이렇게 다른 라이프 사이클을 가진 기능 두개를 하나의 코드로 묶어 관리하는 것은 좋은 유지 보수 방식이 아니다.

따라서, JSP 템플릿은 화면을 렌더링하는데 최적화가 되어 있기 때문에, 그 부분만 담당하는 것이 가장 효과적인 유지보수 방식이다.

---

드디어 기어나온 MVC

오래 걸렸다.. 여태 수도 없이 말했던 서블릿과 JSP의 한계점을 극복하기 위해 등장한 개념이 바로 MVC : Model View Controller 패턴이다.

MVC 패턴의 흐름

JSP로 처리하던 로직을 Controller 와 View로 역할을 나누고, 현대 웹 애플리케이션 대부분은 MVC 패턴을 사용하고 있다.

MVC 패턴의 개념을 살짝만 찍먹해보자.

 

Controller

먼저 컨트롤러는 HTTP 요청을 받아서 파라미터를 파싱하고, 비즈니스 로직을 수행한다.

이후 View에 전달할 데이터를 조회하여 Model에 담는 역할을 한다.

컨트롤러에 비즈니스 로직을 둘 수도 있겠지만, 사실 HTTP 요청을 받고 비즈니스 로직까지 수행하기엔 컨트롤러가 너무 많은 역할을 부담한다. 그래서 우리가 흔히 아는 Service라는 계층에 비즈니스 로직을 만들어 처리하는 방식을 사용한다.

서비스 계층을 사용하게 되면 컨트롤러는 단순히 HTTP 요청을 처리하고 서비스를 호출 하기만 하므로 부담이 많이 줄어들게 된다.

 

Model

뷰에 출력할 데이터를 담는다.

뷰가 필요한 데이터를 모두 모델에 담기 때문에 뷰는 비즈니스 로직이나 데이터 접근을 몰라도 되고, 오로지 화면을 그리는데만 집중할수 있게 된다.

 

View

모델에 담겨 있는 데이터를 사용하여 화면을 그리는 일에 집중한다.

 

다음부턴 JSP에 MVC 패턴을 적용해보겠다 !