이전 게시글을 통해 서블릿과 JSP의 연관관계를 이해할 수 있었다. 이번에는 이들의 문제점을 개선한 MVC패턴에 대해 알아보려고 한다.
MVC 패턴의 등.장
servlet과 JSP는 비즈니스 로직과 view를 한 곳에서 처리를 한다.
servlet은 비즈니스 로직을 작성하고 유지보수하는데 편리하지만 view를 구현하기가 불편하다.
JSP는 view를 구현하기 편리하지만 비즈니스 로직을 작성하고 유지보수하는데 불편하다.
이러한 servlet과 JSP의 단점을 버리고 장점만을 활용하기 위해 등장한 디자인패턴이 바로 MVC패턴이다. MVC패턴은 MVC1과 MVC2가 존재한다.
MVC 패턴이란
Model-View-Controller의 약자로 애플리케이션을 개발할 때 구성 요소를 이와같은 3가지 모듈로 역할을 나누어 개발하는 방법론이다.
모델은 View 렌더링에 필요한 데이터 혹은 로직의 처리를 맡는 부분이다. 일반적으로 POJO(Plain Old Java Object)로 구성된다.
모델은 뷰나 컨트롤러에 대해서 어떤 정보도 알지 말아야한다.
뷰는 사용자가 보는 화면을 위한 디스플레이 데이터 또는 프레젠테이션을 맡는 부분으로 Model 데이터의 렌더링을 담당한다.
뷰는 받은 데이터를 화면에 표시해주는 역할만을 수행해야하며 모델에게 전달받은 데이터를 별도로 저장하지 않아야 한다.
JSP 이외에도 Thymeleaf, Groovy 등 여러 Tempate Engine이 있다.
컨트롤러는 뷰와 모델의 중간다리 역할을 수행한다. View와 Model에 대한 사용자의 입력이나 요청에 대해 비즈니스 로직 처리 후 그 결과를 Model에 담아 View에 전달하는 것을 맡는 부분이며 Servlet이 담당한다.
그래서 모델이나 뷰는 서로의 존재를 모르지만 컨트롤러는 이들을 중재하기 위해 모델과 뷰의 정보에 대해 알고있다.
MVC1 패턴
위의 그림은 MVC1 아키텍쳐의 구조를 나타낸 것이다. 브라우저(사용자)로부터 요청이 들어오면 DB로부터 필요한 데이터를 받은 Model 객체(Java Bean)를 JSP 페이지(View)에 담아 응답으로 보내는 것이다. 하지만 위의 구조는 결과적으로 View와 Controller 역할을 JSP가 모두 담당하기 때문에 JSP Page 내에 너무 많은 코드가 들어가 복잡해질 가능성이 크다. 따라서 이러한 점을 보완한 것이 아래의 MVC2 아키텍쳐이다.
MVC2 패턴
MVC 패턴에 맞게 Model, Controller, View 부분로 모듈화 됐고 JSP는 로직 처리가 없이 단순히 Client에게 보여지는 뷰만을 담당한다.
이 방식은 각각이 모듈화되어 있어 유지보수가 매우 쉬워지는 큰 장점이 있다.
마무리
spring MVC는 MVC2 패턴을 채택한다고 한다. 다음에는 spring MVC에 대해 알아보기 전 Front Controller Pattern에 대해 알아보려고 한다.
