MVC 패턴 정리1

Servlet 과 JSP의 한계

- 서블릿으로 개발할 때 뷰(View)화면을 위한 HTML을 만드는 작업은 자바 코드에 섞여서 복잡하고 보기도 좋지 않았다.

서블릿으로만 개발했을 때 뷰(View)화면을 위한 HTML생성 작업

- 이러한 문제들로 인해 JSP 라는 템플릿 엔진들을 사용했고 HTML 작업을 깔끔하게 처리할 수 있게 되었지만 , JSP 코드에 너무 많은 Java 코드와 HTML 코드 등 섞여 있어 만약 내가 실제 프로젝트에 투입되서 JSP가 Java 코드와 섞여있는데 그게 또 수천줄이 넘어간다면.. 유지보수를 하기에는 정말 너무 힘들었을 것 같다.

 

MVC(Model View Controller) 패턴의 등장

- 위 같은 문제들을 해결하기 위하여 등장한 패턴이 바로 MVC 패턴이다.

- 하나의 서블릿과 JSP로 많은 비즈니스 로직과 데이터를 처리해야 했던 예전과 달리 MVC 패턴을 적용하여 컨트롤러(Controller)와 뷰(View)영역으로 서로 각자 역할을 나눠 역할게 맞게 업무를 수행하도록 하였다.

- 컨트롤러(Controller)에서는 웹 브라우저에서 보낸 HTTP요청을 받아 파라미터를 받고 , 비즈니스 로직을 실행한 다음 , 

 화면(VIew)에 전달할 데이터를 모델(Model)에 담는다.

- 모델(Model)컨트롤러가 조회한 데이터를 담아두고 담은 데이터를 화면(VIew)에 전달해준다.

- 뷰(View)에 필요한 데이터가 전부 모델(Model)에 담겨 있기 떄문 에 화면(VIew)에서는 컨트롤러에서 수행하는 비즈니스 관련 로직들이 어떻게 수행되는지 알 필요가 전혀 없기 때문에 모델(Model)이 전달한 데이터를 받아 화면을 구성하는 일만을 담당하게 된다.

초기와 다르게 각 역할을 수행하게 되는 MVC 1 패턴

출처 : https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-mvc-1/dashboard

스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술 - 인프런 | 강의

 

MVC패턴의 한계

- 덕분에 컨트롤러(Controller)의 역할과 뷰(View)를 렌더링 하는 역할을 명확하게 구분할 수 있지만 컨트롤러에 중복이 많고, 필요하지 않는 코드들도 많이 생긴다.

 

각 로직을 처리하는 컨트롤러의 중복 코드들

- 위 그림과 같이 컨트롤러마다 ViewPath나 dispatcher.forward 같이 화면(View)로 이동하는 코드가 항상 중복 호출되야하고 메서드를 공통화 시키더라도 메서드도 항상 직접 호출해야한다.

- 매개변수인 HttpServletReqeust 나 HttpServletResponse도 보면 코드를 사용하지 않을 떄도 발생한다. 

- 결국 이러한 문제를 발생 시키다 보면, 기능이 많아지고 복잡해질수록 공통으로 처리해야 하는 부분이 그만큼 많아지고 

 공통으로 메서드를 처리해도 메서드의 호출 중복이 되는건 똑같다. 그말은 즉, 성능이나 유지보수 측면에서 바라봤을 때 전혀 좋지 않다. 

 

- 이런 문제들을 해결하기 위해 패턴이 하나 더 추가되었는데 바로 Front Controller 패턴이다. 

 

다음번에는 Front Controller 패턴에 대하여 공부를 해보자