서블릿만을 이용한 웹 애플리케이션 개발의 문제점
WAS가 필요했던 근본적인 이유가 무엇인가? 그건 바로 '동적 리소스' 를 제공하기 위함이었다.
따라서, 개발자는 자바에서 제공하는 서블릿을 이용한 프로그램 코드로 상황에 따라 변하는 동적 리소스를 제공할 수 있게 되었다. 또, 서블릿을 지원하는 아파치 톰캣 같은 WAS가 개발되면서, 웹 애플리케이션 개발자는 애플리케이션이 제공하는 비즈니스성 주요 기능 개발에만 집중할 수 있게 되었다.
그런데, WAS가 동적 리소스를 제공한다 해도, 결국 웹 애플리케이션에서 사용자에게 제공되는 것은 웹페이지이다.
즉, 서버에서는 동적으로 웹페이지(HTML에 해당)를 생성하여 사용자에게 제공한다는 것이다. 그렇기 때문에, 어디선가는 HTML을 작성해야만 한다.
서블릿과 자바 코드만으로 HTML을 작성한다면, 비즈니스 로직이 들어가야하는 코드에 HTML을 작성하는 코드가 대부분을 차지하게 된다. 이는 유지보수 측면에서 매우 비효율적이고, HTML 작성 코드 + 비즈니스 로직 코드가 섞여있게 된다면 코드 자체도 매우 복잡해진다.
템플릿 엔진의 등장
그래서 다음과 같은 방법이 제안된다.
"HTML 문서에 동적으로 변경해야하는 부분만 자바 코드를 넣을 수 있다면, 더 편리할 것이다!"
이것이 바로 템플릿 엔진이 생겨난 이유이다.
템플릿 엔진을 사용하면, HTML 문서에서 동적으로 변경이 필요한 부분에만 코드를 적용할 수 있다. 자바를 이용한 템플릿 엔진에는 JSP, Thymeleaf, Freemarker, Velocity 등이 있다.
서블릿과 JSP의 한계
서블릿과 자바코드만으로 웹 애플리케이션을 개발할 때는 사용자에게 보여지는 View(뷰) 화면을 위한 HTML를 작성하는 코드가 비즈니스 로직 코드와 섞여서 지저분하고 복잡했었다.
이를 해결하기 위해 템플릿 엔진인 JSP를 사용해서 HTML은 따로 깔끔하게 작성하고, HTML내 중간중간 동적으로 변경이 필요한 곳에만 자바 코드를 적용했다. 템플릿 엔진을 사용함으로써, 이전보다는 깔끔하게 코드를 작성할 수 있게 되었다.
하지만, 이렇게 하더라도 여전히 고민거리가 남는다. 그것은 바로 JSP가 너무 많은 역할을 한다는 것이다.
하나의 JSP 파일 안에 비즈니스 로직 코드와 HTML 코드(마크업 코드 자체)가 동시에 들어있어서 여전히 유지보수 측면에서 매우 비효율적이다.
따라서, 비즈니스 로직은 서블릿처럼 다른 곳에서 처리하고, JSP 같은 템플릿 엔진은 HTML로 화면을 그리는 일에만 집중하도록 두 역할을 분리해야한다.
MVC 패턴의 등장
하나의 서블릿이나 JSP만으로 비즈니스 로직과 뷰 렌더링까지 모두 처리하게 되면, 너무 많은 역할을 하게 되고, 결과적으로 유지보수가 어려워진다.
더 중요한 문제는 비즈니스 로직을 수정하는 일과 UI를 수정하는 일은 각각 다르게 발생할 가능성이 매우 높고 대부분 서로에게 영향을 주지 않는다는 점이다. 변경의 라이프 사이클이 다른 부분을 하나의 코드로 관리하면, 유지보수성이 매우 안좋아진다.
따라서, JSP 같은 뷰 템플릿은 화면을 렌더링하는 업무에 최적화 되어있기 때문에 이 부분의 업무만 담당하는 것이 효과적이다. 이러한 역할의 분리를 위해서 MVC 패턴이 등장하게 되었다.
MVC 패턴이란 웹 애플리케이션의 비즈니스 로직과 뷰 렌더링을 하나의 코드로 처리하던 것을 Model, View, Controller 라는 3개의 역할로 나누어서 처리하는 디자인 패턴을 말한다.
Model, View, Controller는 각각 아래와 같은 역할을 수행한다.
Model : 뷰의 렌더링에 필요한 데이터를 보관
View : 모델에 담겨 있는 데이터를 사용해서 화면을 렌더링
Controller : HTTP 요청을 받아 파라미터를 검증, 비즈니스 로직을 실행하고 뷰에 전달할 데이터를 조회하여 모델에 보관
서블릿과 JSP를 이용한 MVC 패턴 적용
서블릿을 컨트롤러로, JSP를 뷰로, HttpServletRequest를 Model로 사용하면 간단하게 MVC 패턴을 적용할 수 있다.
참고.
HttpServletRequest 클래스가 제공하는 setAttribute() 메서드를 사용하면, HttpServletRequest 인스턴스에 데이터를 보관해서 뷰에 전달할 수 있다. 뷰는 getAttribute() 메서드로 데이터를 꺼내 사용하면 된다.
MVC 패턴 덕분에 컨트롤러 로직과 뷰 로직을 확실하게 분리할 수 있다. 이렇게 역할을 분리하게 되면, 향후에 화면의 수정이 필요하면 뷰 로직만 변경하면 되고, 비즈니스 로직의 수정이 필요하면 컨트롤러 로직만 변경하면 된다.
고로, 유지보수성이 좋아진다!
MVC 패턴의 한계
분명 MVC 패턴을 적용함으로써 역할의 분리를 깔끔하게 수행할 수 있었다.
그런데도, 개발자의 귀찮음을 해결하려는 욕심은 끝이 없다. 서블릿과 JSP, HttpServletRequest(이것도 사실 서블릿에 속하는 녀석이다) 만으로 MVC 패턴을 적용하니 아래와 같은 단점이 남아있다.
- 중복되는 코드가 많다 : JSP로의 포워드 중복 호출, viewPath 중복 등
- 사용하지 않는 코드가 존재한다 : HttpServletRequest, HttpServletResponse를 매번 모두 사용하지 않음
- 공통 처리가 어렵다 : 단순히 공통 기능을 메서드로 뽑는 것으로는 공통 처리와 관련된 근본적 문제를 해결할 수 없음
정리하면, 공통 처리가 어렵다는 문제가 있다.
이 문제를 해결하려면, 컨트롤러 호출전에 공통 기능을 처리해주는 소위 수문장 역할을 하는 기능이 필요하다
프론트 컨트롤러(Front Controller) 패턴을 도입하면 이런 문제를 깔끔하게 해결할 수 있다.
스프링이 제공하는 스프링 MVC의 핵심도 바로 이 프론트 컨트롤러에 있다.
