프론트 컨트롤러 패턴와 어댑터 패턴

MVC 패턴의 문제점

MVC 패턴을 적용해서 View 영역은 Model에서 데이터를 참조하여 화면을 그리는 역할만 수행하면 됐다. 하지만 Controller 에 해당하는 부분은 여전히 문제를 가지고 있다.

 

Contorller의 문제점

1. dispacher.forward(request, response) View로 이동하는 forward가 항상 중복 호출된다.
2. String path = "/WEB-INF/views/new-form.jsp" View의 path 입력을 중복 작업한다.
   • jsp 파일의 경로 혹은 이름이 바뀌면 적용된 코드 전부가 변경되어야 한다.
   • JSP 이외의 확장자를 사용하려면 전체가 변경되어야 한다.
3. HttpServletResponse 객체를 사용하는 경우가 적다.(JSP에서 모두 해결하기 때문에)
4. 공통 기능이 추가될 수록 Controller에서 처리해야 하는 부분들이 많아진다.

 

프론트 컨트롤러 패턴

프론트 컨트롤러 패턴은 Servlet(Controller)이 호출되기 전에 공통 기능을 하나의 Servlet에서 처리해주는 패턴이다. 

 

프론트 컨트롤러(Servlet) 하나에 모든 클라이언트 요청이 들어온다.

 

프론트 컨트롤러 패턴 구조

 

프론트 컨트롤러의 역할

• 모든 요청을 하나의 프론트 컨트롤러가 받는다.
• 공통 기능을 처리한다.
• 요청을 처리할 수 있는 Controller를 찾아서 호출한다.(Controller Mapping)
• 프론트 컨트롤러를 제외한 나머지 컨트롤러는 Servlet을 사용하지 않아도 된다.
  • 일반 Controller들은 HttpServlet을 상속받거나, @WebServlet을 사용하지 않아도 된다.

 

프론트 컨트롤러 의문점

프론트 컨트롤러를 사용하면 모든 컨트롤러에서 같은 형태의 응답을 해야하는가?

위 그림처럼 공통 처리 로직에 모든 컨트롤러가 연결되기 위해서는 모든 컨트롤러가 return 하는 결과의 형태가 동일해야 한다.

 

하지만, Controller 마다 로직이나 응답해야하는 결과는 당연히 다를테고 응답을 동일하게 맞추려고 한다면 해당 애플리케이션은 확장성, 유지보수성을 잃는다.

 

이것을 해결하기 위해 고안 된 것이 어댑터 패턴이다!

 

어댑터 패턴

어댑터 패턴은 다양한 컨트롤러(Handler)를 유연하게 만들기 위해 어댑터 패턴을 도입하게 되었다.

 

컨트롤러들은 동일한 인터페이스를 구현하도록 하고 해당 인터페이스와 공통 로직 사이에 어댑터를 두어 유연하게 만든다.

 

서로 다른 인터페이스를 갖는 두 클래스를 연결해주는 패턴이다.

 

어댑터 패턴 구조

• 컨트롤러(Handler)는 비즈니스 로직을 처리하고 알맞은 결과를 반환한다.
• 어댑터는 공통 로직과 컨트롤러가 자연스럽게 연결되도록 한다.
• 프론트 컨트롤러는 공통으로 처리되는 로직을 수행한다.

 

어댑터 패턴 장점

프론트 컨트롤러, 어댑터, 핸들러 모두 각자의 역할만 수행한다. (책임 분리)

 

새로운 컨트롤러가 추가되어도 컨트롤러와 어댑터만 추가한다면 프론트 컨트롤러의 공통 처리로직의 변경이 발생하지 않는다.