너무 많은 역할
- 하나의 서블릿이나 JSP만으로 비즈니스 로직과 뷰 렌더링까지 모두 처리하게 되면 너무 많은 역할을 하게 되고 결과적으로 유지보수가 어려워진다.
- 비즈니스 로직을 호출하는 부분에 변경이 발생해도 해당 코드를 손대야 하고 UI를 변경할 일이 있어도 비즈니스 로직이 있는 해당 파일을 수정해야 한다.
변경의 라이프 사이클
- 이 문제는 비즈니스 로직과 UI 사이에 변경의 라이프 사이클이 다르다는 점이다.
- UI를 일부 수정하는 일과 비즈니스 로직을 수정하는 일을 각각 다르게 발생할 가능성이 매우 높고 대부분 서로에게 영향을 주지 않는다.
- 이렇게 변경의 라이프 사이클이 다른 부분을 하나의 코드로 관리하는 것은 유지보수하기 좋지 않다.
기능 특화
- 뷰 템프릿은 화면을 렌더링 하는데 최적화 되어 있기 때문에 이 부분의 업무만 담당하는 것이 가장 효율적이다.
Model View Controller
- MVC 패턴은 하나의 서블릿이나, JSP로 처리하던 것을 Controller, View라는 영역으로 서로 역할을 나눈 것을 말한다.
컨트롤러
- HTTP요청을 받아서 파라미터를 검증하고 비즈니스 로직을 실행한다. 그리고 뷰에 전달할 결과 데이터를 조회해서 모델에 담는다.
모델
- 뷰에 출력할 데이터를 담아둔다.
- 뷰가 필요한 데이터를 모두 모델에 담아서 전달해주는 덕분에 뷰는 비즈니스 로직이나 데이터 접근을 몰라도 되고 화면을 렌더링 하는 일에 집중할 수 있다.
뷰
- 모델에 담겨있는 데이터를 사용해서 화면에 그리는 일을 집중한다.
MVC 패턴
- 클라이언트가 Controller를 호출한다.
- Controller는 파라미터를 꺼내서 HTTP 요청이 제대로 맞는지 체크한다.
- 요청이 올바르면 Service, Repository 같은 비즈니스 로직을 호출해서 데이터에 접근한다.
- Controller는 비즈니스 로직의 결과를 모델에 담는다.
- View 로직에서 Model에 담겨있는 데이터를 참조해서 응답한다.
MVC 패턴 - 한계
포워드 중복
- View로 이동하는 코드가 항상 중복 호출되어야 한다.
RequestDispatcher dispatcher = request.getRequestDispatcher(viewPath); dispatcher.forward(request,response);
사용하지 않는 코드
- 아래의 코드는 사용할 때도 있고 사용하지 않을 때도 있다.
HttpServletRequest request, HttpServletResponse response
공통 처리가 어렵다.
- 기능이 복잡해질수록 컨트롤러에서 공통으로 처리해야 하는 부분이 점점 더 많이 증가할 것이다.
- 단순히 공통 기능을 메소드로 뽑으면 될 것 같지만 결과적으로는 해당 메소드를 항상 호출해야 하고 실수로 호출하지 않으면 문제가 될 것이다.
- 그리고 호출하는 것 자체도 중복이다.
해결 방안
- 컨트롤러 호출 전에 공통 기능을 처리하는 Front Controller 패턴을 도입하면 해결할 수 있다.
현시깁니다