FrontController 패턴

웹 서버 만들기 프로젝트를 진행하며 프론트 컨트롤러 패턴에 대해 학습하고 작성한 글입니다. 학습과정에서 작성했기 때문에 잘못된 내용이 있을 수 있으며, 

 

 

 

 

 

1. 서블릿과 jsp

---

서블릿을 사용하면 동적으로 html을 작성할 수 있는데요, 하지만 자바코드로 text/html을 다루기 때문에 메시지 body에 text/html과 인코딩 방식(utf-8)과 같은 정보를 직접 넣어줘야 합니다. 이는 (자바로 html을 다루기 때문에) 복잡하고 비효율적인 방식이며 requestParam( ) 메서드는 반환 타입이 String이기 때문에 형 변환 또한 강제로 해줘야 하는 문제도 있습니다.

 

저장의 경우 html코드에 동적으로 데이터를 넣을 수 있게 된다. 

 

 

 

 

 

이를 극복하기 위해 jsp를 사용하게 됐는데요, 뷰를 생성하는 작업을 jsp가 가져가고 동적으로 변경이 필요한 부분에만 자바 코드를 적용해서 서블릿에 몰린 과도한 책임을 분리했습니다. 하지만 여기에도 문제가 있었는데 뷰에 java코드, 데이터를 조회 등 다양한 코드가 노출되기 때문에 jsp가 너무 많은 역할을 하는 문제가 발생하게 됩니다.  

 

서블릿으로 개발할 때는 화면(View)을 위한 HTML을 만드는 작업이 자바 코드에 섞여서 지저분하고 복잡했다.

 

 

 

 

 

2. MVC패턴의 등장

---

서블릿을 이용하던 기존 방식의 불편함으로 인해 MVC 패턴이 등장하게 됩니다. 프로그램에서 변경 주기가 다를 때는 이들을 분리해야 하는데요, 따라서 하나의 JSP로 처리하던 것을 컨트롤러/뷰라는 각각의 영역으로 역할을 나누었으며 이것이 Controller/ModelAndView가 됩니다. 

 

모델에 데이터를 담아서 전달한다.

 

 

 

 

 

 

뿐만 아니라 기존의 컨트롤러(서블릿)은 데이터의 전달과 비즈니스 로직의 수행 등 너무 많은 역할을 했기 때문에 비즈니스 로직은 서비스에 위임하게 됩니다. 즉, 서블릿 컨트롤러가 요청을 받고 비즈니스 로직을 실행한 후 Model에 담아서 데이터를 편리하게 출력하게 해주는 것입니다.

 

 

비즈니스 로직은 서블릿이 아닌 다른곳에서 처리하고, jsp는 목적에 맞게 html로 화면을 그리는 일에 집중하는 것입니다. 이를 통해 화면에 대한 수정이 발생하게 되더라도 이에 대한 로직을 분리할 수 있게 되며, 또한 모델 덕분에 뷰에서 처리하던 비즈니스 로직의 호출을 끊어버릴 수 있게 됩니다. **뷰는 xml, html 등 다양한 종류가 존재합니다. 

 

 

 

 

 

 

 

 

서블릿을 호출하면 forward는 서버 내부에서 호출이 일어나게 되며 이는 redirect보다 성능이 좋습니다.

 

 

 

 

 

 

추가로 static 경로에 파일을 넣게 되면 외부에서도 이를 자유롭게 호출할 수 있지만 아래와 같이 특정 경로에 파일을 넣으면 반드시 컨트롤러를 거쳐서 이를 호출해야 합니다. ** 이는 WAS 서버의 룰인데요, 우리눈에서는 안 보이지만 url을 호출하는 순간 forward가 실행됩니다. 이는 일반적으로 redirect보다 성능이 좋습니다. 

 

 

 

 

 

 

리다이렉트는 실제 클라이언트(웹 브라우저)에 응답이 나갔다가, 클라이언트가 redirect 경로로 다시 요청을 하는 것입니다. 따라서 클라이언트가 인지할 수 있고, URL 경로도 실제로 변경됩니다. 반면에 포워드는 서버 내부에서 발생하는 호출이기 때문에 클라이언트가 전혀 인지하지 못합니다. 

 

request.setAttribute에 데이터를 담아서 편리하게 뷰를 호출할 수 있게 된다.

 

 

 

 

 

 

 

3. MVC 패턴의 한계

---

하지만 여기에도 여전히 단점이 존재하는데요, 우선 컨트롤러의 포워드 로직과 경로의 중복이 많은 것입니다. 중복 로직이 많다는 것은 공통 처리가 어렵는 것인데요, 컨트롤러의 수가 많아지고 기능이 복잡해질 수록 중복 로직이 증하게 됩니다. 물론 공통 기능을 메서드로 뽑아서 해결할 수도 있지만 컨트롤러가 해당 클래스에 의존하게 되기 때문에 좋은 방법이 아닙니다. ** jsp가 아닌 thymeleaf 같은 다른 뷰로 변경한다면 전체 코드를 다 변경해야 하는 문제점도 있습니다.

 

ViewPath에 중복 이는prefix, suffix로 해결할 수 있습니다.

 

 

 

 

뿐만 아니라 HttpServletResponse과 같이 사용하지 않는 코드도 존재하게 됩니다. 이런 문제를 해결하려면 컨트롤러 호출 전에 먼저 공통 기능을 처리하고 해당 기능에 맞는 컨트롤러를 호출해야 합니다. 즉, 중복 로직/경로를 제거하는 것인데 이는 스프링 MVC의 핵심로직이기도 합니다. 다음 글에서는 프론트 컨트롤러의 다음 버전이 어떻게 공통 기능을 처리하는지 살펴보겠습니다.

 

포워드 중복