본문 바로가기
[Spring]/Spring MVC

자바에서의 MVC 패턴(Servlet -> JSP -> 스프링 MVC까지)

by 팡펑퐁 2023. 3. 16.
728x90

Servlet을 활용한 동적 웹페이지 

  • 자바를 통해 서블릿과 자바코드만으로 HTML 문서를 만들 수 있다. 서블릿을 이용하면 정적인 HTML 문서에 회원 정보나 회원 목록과 같은 동적인 요소를 넣은 동적 웹 페이지를 만들 수 있다. 그러나 이는 매우 복잡하고 비효율적이다.

 

 

탬플릿 엔진

  • 자바 코드로 HTML을 만드는 것보다 HTML 문서에 동적으로 변경해야 하는 부분을 자바 코드로 넣는 것이 더 편리할 것이다. 이러한 아이디어에서 나온 것이 바로 템플릿 엔진이다. 앞서 언급했듯이 템플릿 엔진을 사용하면 HTML 문서에 필요한 부분만 자바 코드를 적용하여 동적으로 변경할 수 있다.
  • 템플릿 엔진은 JSP, Thymeleaf, Freemarker, Velocity 등이 있다.

 

 

Servlet과 JSP의 한계

 서블릿과 자바코드만으로 뷰(View) 화면을 위한 HTML을 만드는 작업은 자바 코드로 인해 매우 지저분하고 복잡하다. 이러한 고민에서 나온 템플릿 엔진 중 하나인 JSP는 뷰를 생성하는 HTML 작업을 깔끔하게 처리할 수 있고, 동적으로 변경이 필요한 부분만 자바코드를 적용하여 꽤 실용적인 모습을 보여준다.

 

 그러나, JSP는 혼자서 너무 많은 역할을 한다. 하나의 코드에서 비즈니스 로직과 뷰 영역이 공존하는 등 다양한 코드가 모두 JSP 하나에서 다뤄지고 있다. 작은 프로젝트라면 크게 상관없겠지만 실무에서 수백, 수천줄이 넘어가는 JSP를 생각한다면 유지보수는 지옥과도 같을 것이다. 사용자 인터페이스(UI)를 변경하는 일이 생겨도 비즈니스 로직이 함께 있는 파일을 수정해야 한다. HTML 코드를 수정하는 일에 자바코드가 개입된 파일을 건드리는 것은 전혀 객체 지향적이지 못한 방식이다.

 

 객체 지향적인 설계를 위해 하나의 파일은 하나의 기능만을 담당하는 것이 좋다. 뷰 템플릿은 화면을 렌더링 하는 부분만 담당해야 하고, 비즈니스 로직은 비즈니스 로직만 모아놓고 처리해야 한다. 이렇게 각자의 영역에서 서로의 역할에 집중할 수 있도록 나누자는 생각에서 나온 것이 MVC 패턴이다.

  • 비즈니스 로직(Business Logic) : 실제 요청 사항을 처리하기 위해 Java 코드로 구현한 것

 

 

MVC 패턴

  • 하나의 애플리케이션을 구현할 때 구성 요소를 Model, View, Controller 세 가지 역할로 나누어 개발하는 디자인 패턴을 의미한다. 소프트웨어의 비즈니스 로직과 화면 구현을 구분하는 것에 포커싱 되어있으며, 이러한 관심사 분리를 통해 객체 지향적인 설계(역할의 분리, 높은 유지보수성)를 가능하게 한다.
  • 보통 웹 애플리케이션은 이 MVC 패턴을 사용한다.

 

Model

  • View에 출력할 데이터를 담아둔다. View가 필요한 데이터는 모두 Model이 가지고 있다가 전달해 준다.
  • Model이 있기 때문에 View는 비즈니스 로직이나 데이터 접근을 신경 쓰지 않아도 된다.

 

View 

  • Model 데이터를 이용해서 웹브라우저 같은 클라이언트 애플리케이션의 화면에 보이는 리소스를 제공하는 역할을 한다.
  • 화면을 렌더링 하는 일에 집중한다.

View의 대표적 형태

  • HTML 페이지의 출력
    • HTML 페이지를 직접 렌더링 함
    • 프런트엔드와 백엔드가 통합된 구조
  • PDF, Excel 등의 문서 형태로 출력
  • XML, JSON 등의 특정 형식의 포맷으로 출력

 

Controller

  •  클라이언트 측 요청을 직접적으로 전달받는 엔드포인트로, HTTP 요청을 받아 파라미터를 검증하고 비즈니스 로직을 실행한다.
  • View에 전달할 데이터를 조회해서 모델에 담는다.

 

 

기존 MVC 패턴의 한계

  • MVC 패턴을 적용한 덕분에 Controller의 역할과 View 역할의 명확한 구분이 가능해졌다. 그러나, 서블릿과 JSP만으로 나눈 MVC 패턴은 한계를 가지고 있다. View의 경우에는 화면을 그리는 역할에 충실한 덕분에 코드가 깔끔하고 직관적이다. 그러나 Controller의 경우 서블릿만을 사용하면 중복이 많아지고 필요 없는 코드들이 많아진다.
  • HttpServletRequest와 HttpServletResponse를 사용하는 코드는 테스트 케이스를 작성하기 어려울 뿐만 아니라 공통처리 역시 복잡하다. 이 문제를 해결하려면 Controller 호출 전에 공통 기능을 처리해야 한다. 말 그대로 수문장 역할을 하는 기능이 필요해 보인다. 이를 해결할 수 있는 것이 바로 프런트 컨트롤러(Front Controller) 패턴이다. 스프링 MVC의 핵심도 여기에 있다.

계속 작성 중..

728x90