[MVC] 서블릿, JSP, MVC 패턴(3)

공부 내용을 정리하고 앞으로의 학습에 이해를 돕기 위해 작성합니다.

 

MVC 패턴 - 개요

 

너무 많은 역할

하나의 서블릿이나 JSP로 비즈니스 로직과 뷰 렌더링까지 모두 처리하면 코드의 역할이 과중해지고, 유지보수가 어려워진다. 비즈니스 로직이나 UI 변경이 발생할 때마다 해당 파일을 수정해야 하며, 비효율적인 코드 구성이 된다. 예를 들어, 수백 줄의 자바 코드와 함께 HTML 코드를 수정하거나, 반대로 수백 줄의 HTML 코드와 함께 자바 코드를 수정해야 하는 상황을 상상해 보라.

 

변경의 라이프 사이클

비즈니스 로직과 UI는 변경의 주기가 다르다. UI 수정과 비즈니스 로직 수정은 서로 다른 이유로 발생하며, 각각이 독립적으로 수정되는 경우가 많다. 서로 다른 라이프 사이클을 가진 코드를 하나의 파일에 두면 유지보수가 복잡해진다.

 

기능 특화

특히 JSP와 같은 뷰 템플릿은 화면을 렌더링 하는 데 최적화되어 있다. 따라서 뷰 작업은 JSP에 집중하고, 비즈니스 로직은 다른 계층에서 처리하는 것이 이상적이다.

 

Model-View-Controller (MVC) 패턴

MVC 패턴은 하나의 서블릿이나 JSP로 처리하던 기능을 컨트롤러(Controller)와 뷰(View)로 분리하여 역할을 나눈 아키텍처다. 웹 애플리케이션은 보통 이 MVC 패턴을 따른다.

1. 컨트롤러: HTTP 요청을 받아 파라미터 검증, 비즈니스 로직 호출, 뷰에 전달할 결과 데이터를 조회하고 이를 모델에 담는다.
2. 모델: 뷰에 전달할 데이터를 담는다. 뷰는 비즈니스 로직이나 데이터 접근에 대해 알 필요 없이 화면 렌더링에 집중할 수 있다.
3. 뷰: 모델에 담긴 데이터를 사용해 화면을 렌더링하는 역할을 한다. 이 과정에서 HTML을 생성한다.

참고

컨트롤러에 비즈니스 로직을 두기도 하지만, 컨트롤러의 역할을 경량화하기 위해 비즈니스 로직은 서비스라는 별도의 계층에서 처리하는 것이 일반적이다. 컨트롤러는 비즈니스 로직을 호출하는 역할만 담당하며, 비즈니스 로직이 변경되면 해당 부분을 호출하는 컨트롤러 코드도 일부 변경될 수 있다.

 

MVC 패턴 이전

• 하나의 서블릿이나 JSP가 비즈니스 로직과 뷰 로직을 모두 담당하는 구조다.

MVC 패턴1

 

• 컨트롤러가 비즈니스 로직을 처리하고, 뷰에 데이터를 전달하여 분리된 역할을 수행한다.

MVC 패턴2

 

• 비즈니스 로직은 서비스 계층으로 분리되고, 컨트롤러는 이 로직을 호출하여 데이터를 뷰에 전달하는 방식이다.