MVC 패턴 구현(1) : 모델 2 구조와 MVC 패턴

JSP 웹 어플리케이션의 구조는 크게 모델 1 구조와 모델 2 구조로 나뉜다. JSP에서 모든 로직과 출력을 처리하느냐 아니면 JSP에서는 출력만 처리하느냐에 따라서 모델 1 구조와 모델 2 구조의 차이점에 대해서 살펴보고, 그 뒤에 MVC 패턴과 모델 2 구조의 관계에 대해서 알아보도록 하자.

1. 모델 1 구조

모델 1 구조는 JSP를 이용한 단순한 모델이다. 보통 처음 JSP를 배울 때 사용하는 구조가 모델 1 구조인데, 그 처리 구조는 아래 그림과 같다.

모델 1 구조는 위의 그림과 같이 웹 브라우저의 요청을 JSP가 직접 처리한다. 웹 브라우저의 요청을 받은 JSP는 자바빈이나 서비스 클래스를 사용해서 웹 브라우저가 요청한 작업을 처리하고 그 결과를 클라이언트에 출력한다.

JSP 페이지에서 웹 브라우저가 요청한 것들을 처리한다는 것을 JSP 페이지에 비즈니스 로직을 처리하기 위한 코드와 웹 브라우저에 결과를 출력하는 코드가 섞인다는 것을 의미한다. 예를 들어, 앞서 방명록 예제를 보면 하나의 JSP 페이지에서 서비스 클래스를 통해서 (글쓰기, 읽기 등의) 원하는 작업을 수행하고 그 결과를 출력했는데, 이것이 모델 1 구조의 전형적인 예이다.

2. 모델 2 구조

모델 2 구조는 모델 1 구조와 달리 웹 브라우저의 요청을 하나의 서블릿이 받는다. 서블릿은 웹 브라우저의 요청을 알맞게 처리한 후 그 결과를 보여줄 JSP 페이지로 포워딩한다. 포워딩을 통해 요청 흐름을 받은 JSP 페이지는 결과 화면을 클라이언트에 전송한다. 아래 그림은 모델 2 구조의 요청 처리 순서를 보여주고 있다.

모델 2 구조의 특징은 웹 브라우저의 모든 요청을 단일 진입점, 즉 하나의 서블릿에서 처리한다는 점이다. 하나의 서블릿이 웹 브라우저의 모든 요청을 받기 때문에, 서블릿은 웹 브라우저의 요청을 구분하는 방법이 필요하다. 서블릿은 웹 브라우저의 요청을 처리한 후 웹 브라우저에 보이게 될 응답 화면을 생성할 JSP를 선택한다. 모델 2 구조의 이러한 특징 때문에, MVC(Model-View-Controller : 모델-뷰-컨트롤러) 패턴을 이용해서 웹 어플리케이션을 구현할 때 모델 2 구조를 사용한다.

3. MVC 패턴

MVC(Model-View-Controller; 모델-뷰-컨트롤러) 패턴은 웹 개발자라면 반드시 알아야 하는 패턴이다. MVC 패턴은 스윙(swing)과 같은 UI 컴포넌트뿐만 아니라 웹 어플리케이션 개발 영역에서도 보편적으로 사용되고 있다.

이름에서도 알 수 있겠지만 MVC 패턴은 크게 모델, 뷰, 컨트롤러의 세 부분으로 구성되며, 각각의 구성 요소는 다음과 같은 역할을 담당한다.

• 모델 : 비즈니스 영역의 로직을 처리한다.
• 뷰 : 비즈니스 영역에 대한 프레젠테이션 뷰(즉, 사용자가 보게 될 결과 화면)를 담당한다.
• 컨트롤러 : 사용자의 입력 처리와 흐름 제어를 담당한다.

사용자는 원하는 기능을 처리하기 위한 모든 요청을 컨트롤러에 보낸다. 모델은 비즈니스와 관련된 기능을 제공하는데, 컨트롤러는 이 모델을 이용해서 사용자의 요청을 처리한다. 모델을 사용하여 알맞은 비즈니스 로직을 수행한 후 컨트롤러는 사용자에게 보여줄 뷰를 선택한다. 선택된 뷰는 사용자에게 알맞은 결과 화면을 보여준다. 뷰가 사용자에게 결과 화면을 보여줄 때에는 데이터가 필요한데, 이 데이터는 컨트롤러를 통해서 전달받는다.

MVC 패턴의 핵심은 다음과 같다.

• 비즈니스 로직을 처리하는 모델과 결과 화면을 보여주는 뷰를 분리한다.
• 어플리케이션의 흐름 제어나 사용자의 처리 요청은 컨트롤러에 집중된다.

모델은 비즈니스와 관련된 로직을 처리하면 될 뿐 사용자에게 보일 화면이나 흐름 제어에 대해서는 처리하지 않는다. 반대로 뷰는 사용자에게 알맞은 화면을 보여주는 역할만 수행할 뿐, 비즈니스 로직이나 흐름 제어 등을 처리하지 않는다. 이렇게 모델과 뷰가 분리되어 있기 때문에 모델의 내부 로직이 변경되더라도 뷰는 영향을 받지 않고, 반대로 뷰와 모델이 직접 연결되어 있지 않기 때문에 내부 구현 로직에 상관없이 뷰를 변경할 수 없다.

또한, 컨트롤러는 사용자의 요청에 대해서 알맞은 모델을 사용하고 사용자에게 보여줄 뷰를 선택하면 된다. 비즈니스 로직에는 포함되지 않지만, 전체 웹 애플리케이션에 일괄적으로 적용되는 기능(예를 들어, 사용자 인증)을 컨트롤러에서 처리하게 된다.

웹 어플리케이션의 흐름 제어나 보안 설정이 변경되면 컨트롤러만 변경하면 되고, 새로운 타입의 사용자(예를 들어, 새로운 모바일 기기의 추가)가 새롭게 추가되는 경우 컨트롤러나 모델에 상관없이 새로운 뷰를 추가하면 된다. 즉, MVC 패턴을 사용함으로써 유지보수 작업이 쉬워지고 어플리케이션을 쉽게 확장할 수 있게 된다.

4. MVC 패턴과 모델2 구조의 매핑

위의 그림들을 보면 JSP의 모델 2 구조와 MVC 패턴이 비슷한 것을 알 수 있는데, 실제로 모델 2 구조와 MVC 패턴은 완벽하게 일치한다. 이 둘 사이의 관계를 살펴보면 다음과 같다.

• 컨트롤러 = 서블릿
• 모델 = 로직 처리 클래스, 자바빈
• 뷰 = JSP
• 사용자 = 웹 브라우저 내지 휴대폰과 다양한 기기

모델 2 구조에서 웹 브라우저의 요청은 서블릿으로 전달된다고 했는데, 웹 브라우저의 요청은 곧 사용자의 입력이 된다. 서블릿은 비즈니스 로직을 수행하는 클래스를 사용하여 웹 브라우저의 요청을 처리하며 뷰의 역할을 하는 JSP 페이지를 이용해서 처리 결과를 보여주게 된다.

5. MVC의 컨트롤러 : 서블릿

모델 2 구조에서 서블릿은 MVC 패턴의 컨트롤러 역할을 한다. 서블릿은 웹 브라우저의 요청과 웹 어플리케이션의 전체적인 흐름을 제어한다. 아래 그림은 컨트롤러 역할을 하는 서블릿이 어떤 순서로 실행되는지를 보여주고 있다.

컨트롤러 역할을 하는 서블릿은 위의 그림에서 보듯 크게 5단계의 과정을 거쳐 웹 브라우저의 요청을 처리한다. 각 과정에 대해 더욱 자세하게 살펴보면 다음과 같다.

• 과정1 : 웹 브라우저가 전송한 HTTP 요청을 받는다. 서블릿의 doGet() 메서드나 doPost() 메서드가 호출된다.
• 과정2 : 웹 브라우저가 어떤 기능을 요청했는지 분석한다. 예를 들어, 게시판 목록을 요청했는지, 글쓰기를 요청했는지 알아낸다.
• 과정3 : 모델을 사용하여 요청한 기능을 수행한다.
• 과정4 : 모델로부터 전달받은 결과물을 알맞게 가공한 후, request나 session의 setAttribute() 메서드를 사용하여 결과값을 속성에 저장한다. 이렇게 저장한 결과값은 뷰인 JSP에서 사용한다.
• 과정5 : 웹 브라우저에 결과를 전송할 JSP를 선택한 후, 해당 JSP로 포워딩한다. 경우에 따라 리다이렉트를 하기도 한다.

비즈니스 로직의 처리는 모델에서 이루어진다. 서블릿은 모델이 내부적으로 어떻게 비즈니스 로직을 처리하는지 알 필요 없이, 웹 브라우저의 요청에 따라 알맞게 모델을 사용하여 요청 기능을 실행하고 그 결과를 뷰인 JSP에 전달하면 된다. 웹 브라우저의 결과를 보여줄 JSP 페이지는 컨트롤러 서블릿이 선택한다. 이때, 요청 처리 결과는 request나 session에 저장해서 뷰 역할을 하는 JSP 페이지에 전달한다.

6. MVC의 뷰 : JSP

모델 2 구조에서 JSP는 뷰 역할을 담당한다. 비즈니스 로직과 관련된 코드가 없는 점을 제외하면 일반 JSP와 동일한 형태를 취한다. 뷰 역할을 하는 JSP는 컨트롤러에서 request 기본 객체나 session 기본 객체에 저장한 데이터를 사용하여 웹 브라우저에 알맞은 결과를 출력한다. 뷰 JSP는 컨트롤러 서블릿처럼 일반적인 처리 순서가 정해져 있지는 않다.

뷰 역할을 하는 JSP는 웹 브라우저가 요청한 결과를 보여주는 프레젠테이션의 역할을 할 뿐만 아니라 웹 브라우저의 요청을 컨트롤러에 전달해주는 매개체가 되기도 한다. 예를 들어, 웹 브라우저가 게시판 글 목록 보기를 요청하여 그 결과를 'BoardList.jsp' 뷰를 사용하여 출력했다고 하자. 이때, 'BoardList.jsp'에는 [글쓰기]와 같은 링크가 존재할 것이며, 이 [글쓰기] 링크는 컨트롤러에 연결되어 있을 것이다. 즉, 뷰 역할을 하는 JSP는 웹 브라우저가 지속적으로 컨트롤러에 요청을 보낼 수 있는 링크나 폼을 제공해서 웹 브라우저가 업무 흐름에 따라 컨트롤러에 알맞은 요청을 보낼 수 있도록 한다.

7. MVC 모델

컨트롤러는 서블릿을 통해서 구현하고 뷰는 JSP를 통해서 구현하는데 모델은 명확하게 어떤 것을 통해서 구현한다는 규칙은 없다. 비즈니스 로직을 처리해주면 모델이 될 수 있다. 모델이 제공해야 하는 기능은 웹 브라우저의 요청을 처리하는 데 필요한 기능이다. 예를 들어, 계좌 이체 기능을 요청했다면 모델은 계좌 이체를 시켜주는 기능을 제공해야 하며, 컨트롤러는 웹 브라우저의 요청이 들어오는 경우 모델의 계좌 이체 기능을 사용하게 된다.

위의 그림은 모델의 일반적인 업무 흐름을 보여주고 있다. 컨트롤러 서블릿이 웹 브라우저의 요청을 분석하여 알맞은 모델을 호출하면서부터 모델의 기능이 시작된다. 모델은 컨트롤러가 요청한 작업을 처리한 후 알맞은 결과를 컨트롤러에게 전달하는데, 이때 처리한 결과값을 저장하는 객체로 보통 자바빈을 사용한다. 모델은 서비스 클래스나 DAO 클래스를 이용해서 비즈니스 로직을 수행해야 한다.

참고

• 최범균의 JSP2.3 웹 프로그래밍