MVC 계층

웹 어플리케이션에서는 기존의 MVC Model를 MVCD(Model-View-Controller-Dispatch) 또는 MVC Model 2+1 라고 불러야 한다는 소리가 있다. 그 이유는 웹 어플리케이션에서는 View 화면이 Controller에 의해서 Dispatch되기 때문이다.

MVC에는 다음과 같은 특징이 있다.

장점

 • 표준에 맞는 개발이 이루어지므로 확장성이 뛰어나다.

  • 모듈별 검색이 쉽다.

  • 표준화된 코드를 이용하기 때문에 공동 작업이 용이하고 유지보수가 쉽다.

단점

  • 개발 과정이 복잡해 초기 개발 속도가 늦다.

  • 프로그램 로직을 별도의 자바 클래스나 서블릿을 이용해 처리(소스 변경에 따른 재컴파일, 컨테이너 재시동 등 불편)

  • 초보자가 이해하고 프로그래밍하기에는 다소 어렵다

또 Web Application 에서는 다음과 같은 계층으로 MVC모델을 구현한다. 만들고자 하는 Web Application이 어떤 복잡도를 가지고 있든지 간에, 애플리케이션 아키텍처를 아래의 세 가지 논리 계층으로 나누어서 시작하는 것이 기본적으로 도움이 된다.

프리젠테이션 계층

• 역할 : 프리젠테이션 계층은 말 그대로 사용자 인터페이스에 불과하다. 식당을 예로 들면 손님이 접하게 되는 메뉴판과 전달될 음식을 차려놓는 식탁에 해당한다.
• 기능 : 사용자가 선택할 수 있는 기능이 표시되어 있어야 하고, 요청에 필요한
  부가적인 정보 전달을 위한 입력 양식이 있어야 한다. 또한 전달된 자료를 효과적으로 보여주기 위한 프리젠테이션 로직이 포함된다.
  하지만 비즈니스 로직이나 퍼시스턴스 계층에서 처리하는 일을 직접 수행하거나(스크립트 릿 사용), 각 계층의 컴포넌트와 직접적인
  통신이 있어선 안된다. 
  모든 요청은 제어 계층을 통해 처리되어야 한다는 뜻이다. 고급 레스토랑(엔터프라이즈 시스템)에서는 웨이터(지배인)를 통해서만
  요구를 전달하고, 그 결과를 전해들어야 한다. 직접 주방장에게 주문을 하거나 자기가 직접 요리를 하는 것은 자기
  집(프로토타입)이나 동네 자장면 가게(소규모 웹 애플리케이션)에서나 가능한 일이다.
• 대안 기술 : 현재 가장 주류를 이루는 기술은 JSP 1.2와 JSTL과 같은 태그
  라이브러리를 결합하는 방식이다. 과도기적인 형태로 벨로시티와 타일즈 태그 라이브러리가 결합된 형태도 현재 주목을 받고 있다.
  하지만 점차적으로 JSF에 기반한 JSP 2.0에 주류 기술로 옮겨갈 가능성이 크고, 프리젠테이션 계층 개발에 있어서도 JSF를
  지원하는 IDE를 채택하는 경우가 늘어날 것이다.
• 주요 패턴 : Composite View 패턴

  제어 계층

• 역할 : 제어 계층은 프리젠테이션 계층과 비즈니스 로직 계층을 분리하기 위한 컨트롤러를 제공한다. 식당으로 치자면 지배인의 역할과 종업원의 역할을 병행하는 것이라고 볼 수 있다.
• 기능 : 전체 시스템의 설정 상태를 유지해야 하며, 그를 통해 어떤 요청이 들어왔을
  때 어떤 로직이 처리해야 하는지를 결정한다. 사용자 요청을 검증하고 로직에 요청을 전달하는 일과 로직에서 전달된 응답을 적절한
  뷰에 연결짓는 것 역시 제어 계층의 몫이다.
  손님이 바다가재 요리를 요청했을 때 종업원은 그 요리가 서비스 가능한 것인지 또한 누구에게 시키면 되는지를 알고 있어야 한다는
  뜻이다. 요청을 전달받은 요리사가 바다가재 요리를 주면 그것을 식탁까지 운반해 주는 것 역시 종업원의 몫이다. UI 검증, 요청 및
  응답 전달, 로직에서 던져진 예외 처리, 도메인 모델을 뷰와 연결하기 등의 고유 기능 외에는 어떤 기능도 포함하지 않는다.
• 대안 기술 : 현재 WAF들은 대부분 제어 계층의 핵심 기능을 포함한다. 터빈이나
  에스프레소 등이 선전하고 있지만, 스트럿츠와 웹워크가 대세라고 생각된다. 당분간 별다른 대안 기술이 등장할 가능성은 적다. 오히려
  스트럿츠를 확장시켜 자사 고유의 프레임워크로 최적화 시키는 작업이 활발히 진행될 것이다.

  ◆ 주요 패턴 : Front Controller 패턴, Service to Worker 패턴(또는 Command 패턴),
  Intercepting Filter 패턴, Application Controller & Context Object 패턴

  비즈니스 로직 계층

• 역할 : 비즈니스 로직은 말 그대로 핵심 업무를 어떻게
  처리하는지에 대한 방법을 기술하는 곳이다. 식당에서 종업원이 고객의 요구를 전달해 주면, 재료를 이용해 요리를 만드는 요리사라고나
  할까? 비즈니스 로직 계층은 애플리케이션에서 가장 재사용될 확률이 높은 요소이기 때문에 신경 써서 설계해야 한다.
• 기능 : 비즈니스 로직에는 핵심 업무 로직의 구현과 그에 관련된 데이터의 적합성
  검증 외에도 다양한 부가적인 구현이 추가된다. 트랜잭션 처리라든가, 다른 계층들과 통신하기 위한 인터페이스를 제공한다거나, 해당
  계층의 객체들간의 관계를 관리하는 것 등이 그것이다.
  비즈니스 로직 계층에 있어야 할 코드들이 프리젠테이션 계층이나 퍼시스턴스 계층에 여기저기 흩어져 있는 애플리케이션을 찾아보기란
  그리 어려운 일이 아니다. 이런 구조는 각각의 계층을 모호하게 만들어 유지보수시 많은 시간을 필요로 하게 만든다.
  가장 신경 써서 개발해야 할 비즈니스 로직에 그동안 신경을 쓰지 못했다는 것. 프리젠테이션 계층과 퍼시스턴스 계층 사이의 다리
  역할을 충실히 하도록 함으로써 애플리케이션에 유연성을 더하는 것. 그것이 스프링이 탄생하게 된 배경이라고 할 수 있다.
• 대안 기술 : 지금까지 비즈니스 로직의 구현은 크게 EJB를 사용하는 것과 일반
  자바 객체(POJO)를 사용하는 것으로 나눌 수 있었다. EJB를 사용하는 경우 개발자들의 많은 불만이 EJB 3.0을
  사용함으로써 해결되리라 예상된다. 하지만 해외를 중심으로 해서 EJB를 사용하건, 사용하지 않건 비즈니스 로직들을 체계적으로
  관리하는 IoC 컨테이너에 대한 관심이 증가하고 있는 추세이다. IoC 컨테이너에 대해서는 뒤에서 다시 자세히 살펴보도록 하겠다.
• 주요 패턴 : Business Delegate 패턴, Session Facade 패턴, Service Locator 패턴, Application Service 패턴, EJB Home Factory 패턴

  퍼시스턴스 계층

• 역할
  : 퍼시스턴스 계층은 데이터 처리를 담당하는 계층이다. 주로 데이터의 생성/수정/삭제/선택(검색)과 같은 CRUD 연산을
  수행하게 된다. 식당으로 보자면 주방장이 사용할 재료를 담당하는 재료 담당자라고나 할까? 이 데이터는 주로 데이터베이스에서
  처리되는 경우가 많아, 영속성을 의미하는 퍼시스턴스 계층이란 용어를 사용했다. 하지만 데이터가 처리되는 다른 업무 시스템이나, 웹
  서비스, XML, 파일 시스템 등을 모두 고려한다면 레거시 개념을 갖는 EIS 계층이란 표현이 더 적합할 것이다.
• 기능 : 이 계층에서 수행하는 일은 관계형 정보를 저장하고, 수정/삭제하는 것과, 그러한 일을 수행하는 데 필요한 질의문을 관리하는 것, 그리고 가져온 관계형 정보를 객체화시키는 일이다.
• 대안 기술 : EJB 사용에 있어서 개발자들이 가장 불만스러워 하는 것은 CMP
  방식의 엔티티 빈일 것이다. 그러한 불만은 객체 관계 맵핑(ORM)을 이용한 JDO라는 대안기술을 탄생시켰고, 또한
  하이버네이트라는 또 하나의 오픈소스 기술을 실무로 끌여들였다. JDBC를 이용한 DAO 객체를 구성하는 방법도 소규모
  애플리케이션에서는 여전히 인기를 끌고 있다. EJB 3.0과 JDO/하이버네이트, 그리고 JDBC를 이용한 POJO 방식 중 어떤
  것이 개발자들에게 낙점될 지는 아직 미지수다.
• 주요 패턴 : Data Access Object 패턴, Domain Store 패턴, Sequence Blocks

  도메인 모델 계층

• 역할 : 도메인 모델은 각 계층 사이에 전달되는 실질적인 비즈니스 객체라고 할 수 있다. 식당을 예로 든다면, 음식이 담긴 그릇이라고 비유할 수 있겠다.
• 기능 : 도메인 모델 계층은 흔히 데이터 전송 객체(DTO) 형태로 개발자가 직접
  제작해서, 리퀘스트나 세션과 같은 컨텍스트에 담아 넘기게 된다. 하지만 데이터베이스의 모든 정보를 일일이 객체로 만드는 것은
  귀찮을 뿐 아니라, 계층간의 통신 과정에서 데이터가 유실될 위험도 있기 때문에 최근에는 도메인 모델을 서비스로 제공하여 자동화하는
  경우가 많다.
• 주요 패턴 : Data Transfer Object 패턴, Value List Handler 패턴