MVC 패턴(Model View Controller)
MVC는 Model, View, Controller의 약자로 하나의 애플리케이션을 구성할 때 그 구성요소를 세가지의 역할로 구분한 패턴이다.
MVC 패턴 이전에는 비즈니스 로직과 뷰 로직 등 애플리케이션 구성요소들이 하나로 구성된 경우가 많았다. 이 경우 장점도 있겠지만 많은 단점들이 생겨난다.
- 너무 많은 역할
- 예를 들어 하나의 서블릿이나 JSP만으로 비즈니스 로직과 뷰 렌더링까지 모두 처리할 경우, 화면 변경이 필요한 경우에 비즈니스 로직을 변경해야 할 경우가 발생될 수 있다. 너무 많은 역할을 하게 될 경우 유지보수 시 변경의 이유 또한 많아진다. 이로 인해 유지보수성이 떨어지게 되므로 역할을 나누는 것이 좋다.
- 변경의 라이프 사이클
- 중요한 문제는 비즈니스 로직과 뷰로직은 서로 변경의 라이프 사이클이 다르다는 점이다. UI를 일부 수정하는 일과 비즈니스 로직을 수정하는 일을 각각 다르게 발생할 가능성이 매우 높고 대부분 서로에게 영향을 주지 않는다.
- 기능 특화
- 특히 JSP 같은 뷰 템플릿은 화면을 렌더링 하는데 최적화 되어 있기 때문에 이 부분의 업무만 담당하는 것이 가장 효과적이다.
- Controller: HTTP 요청을 받아서 파라미터를 검증하고, 비즈니스 로직을 실행한다. 그리고 뷰에 전달할 결과 데이터를 조회해서 모델에 담는다.
- Model: 뷰에 출력할 데이터를 담아둔다.
- View: 모델에 담겨있는 데이터를 사용하여 화면을 그리는 일을 담당한다. HTML을 생성하는 부분을 말한다.
MVC 패턴의 한계
MVC 패턴을 적용하면 컨트롤러의 역할과 뷰를 렌더링 하는 역할을 명확하게 구분할 수 있다. 하지만 컨트롤러에서 뷰를 호출하기 위한 중복코드들이 존재하게 된다.
포워드 중복
View로 이동하는 코드가 항상 중복 호출되어야 한다.
1
2
ReqeustDispatcher dispatcher = request.getReqeustDispatcher(viewPath);
dispatcher.forward(request, response);
ViewPath 중복
1
String viewPath = "/WEB-INF/views/new-form.jsp";
공통처리가 어렵다
예를 들어 모든 컨트롤러 실행 전이나 후에 처리할 공통기능을 개발하려 한다면 MVC 구조에서는 모든 컨터롤러에 중복 로직을 작성해야한다. 이 문제를 해결하기 위해서는 모든 컨트롤러 실행전 공통기능을 처리해 줄 무언가가 필요해진다. 이러한 문제는 프론트 컨트롤러(Front Controller)패턴을 도입하면 해결할 수 있다
스프링 또한 프론트 컨트롤러 패턴으로 설계되어 있고 프론트 컨트롤러 패턴은 다음 포스팅에서 다루겠다.
Comments powered by Disqus.