현재의 웹 프로그래밍 환경은 HTML 태그로 하이퍼 링크와 그림만을 입력하던 예전과는 판이하게 틀리다. 변화가 없는 HTML 페이지가 사용자와 상호 작용하여야 하는 경우가 발생하자 CGI (Common Gateway Script)가 등장했다. Perl 또는 C언어로 작성되는 CGI는 사용자의 입력에 따라서 동적인 페이지를 생성했다. 하지만 재 사용 가능한 코드를 쓰기가 거의 불가능에 가까웠고, GGI 프로그래밍은 복잡한 프로그래밍 환경을 만족시키지 못했다. 그 후에 등장한 프로그래밍 모델은 페이지 기반 개발이었다.
ASP또는 PHP로 대표되는 페이지 기반 개발은 여러 계층으로 동작하던 CGI의 복잡성을 줄여주었다. 하지만, 페이지가 갈수록 늘어나고 작성해야 하는 페이지의 수가 말도 못하게 늘어남에 따라 페이지 기반 개발 방식은 프레임워크 기반 방식으로 발전했다. 튼튼하게 제작된 프레임워크는 페이지에 발생하는 복잡함을 줄이는 대신 자신이 대신해 주었다. 프로그래머가 해야 하는 일은 줄어들었다.
프레임워크가 등장함에 따라 페이지를 어떻게 작성할 것인지에 대한 프로그래머의 선택권은 한없이 넓어졌다. 페이지 내에 스크립트를 그대로 유지하는 페이지 기반 프로그래밍 모델을 그대로 사용할 수도 있고, Java의 태그 라이브러리와 ASP.NET의 코드-비하인드를 사용하여 페이지 수준에서 프리젠테이션 로직과 페이지 로직을 구분할 수도 있게 되었다. 소프트웨어의 아키텍처를 정립하고 튼튼한 설계를 기반으로 개발을 시작하는 것은 과도한 복잡성과 중복성을 줄이기 위해서 인데, 웹 응용 프로그램 개발에서 사실상 가장 많이 중복되는 부분은 페이지에서 표현되는 프리젠테이션 계층의 로직들이다. 이런 중복된 내용을 비즈니스 로직 계층으로 옮겨 표현할 수도 있지만, 그렇게 처리한다면 비즈니스 로직 계층의 복잡도가 너무 증가하게 된다.
가장 좋은 방법은 프리젠테이션 계층의 컴포넌트들을 설계하고 이를 재 사용하기 위한 적당한 정도의 복잡성을 가지게 설계하는 것이다. 마이크로소프트의 Enterprise Solution Pattern using Microsoft.net에서는 그 “적당한” 복잡도에 대한 6가지의 질문을 준비하고 그 질문에 대한 대답으로 패턴을 제시한다.
위의 <표 1>은 Enterprise Solution Pattern using Microsoft.net에서 제시하는 질문과 질문에 대한 답으로서의 디자인 패턴이다.
Enterprise Solution Pattern using Microsoft.net은 연구되고 발표된 거의 모든 디자인 패턴을 참고 한다. 디자인 패턴의 교본이라 불리는 GoF의 디자인 패턴을 이해하지 않고서는 웹 프리젠테이션 패턴을 이해하기 힘들다. MVC 패턴은 Observer 패턴을, Page Controller 패턴은 GoF의 패턴중 Template Method 패턴을, Front Controller 패턴은 GoF의 패턴중 Command 패턴을 응용하고 있기 때문이다. 이러한 패턴에 익숙하지 않은 독자들이라면 다시 한번 GoF의 디자인 패턴을 살펴 보기를 바란다. <그림 2>는 웹 프리젠테이션 패턴의 패턴 클러스터이다. (패턴 클러스터에 대해서는 지난 달 연재를 살펴보기 바란다.)
MVC (Model-View-Controller) 패턴
해결책의 쌍으로서 MVC 패턴을 생각해보면 질문은 다음과 같다.
“개별적인 영역을 쉽게 수정하기 위해서 웹 응용 프로그램의 사용자 인터페이스 기능을 어떻게 모듈화 할 것인가?”
질문이 너무 추상적인 것 같이 느껴진다. 질문을 해설해보면 주로 다음과 같은 문제라고 생각할 수 있다.
① HTML 페이지를 설계하는 것과 비즈니스 로직을 설계하는 것은 거의 모든 경우에 다른 기술이 필요하다. 이는 웹 디자이너와 프로그래머의 고질적은 의견 대립을 발생시키는 문제이기도 하다. 빼어난 웹 디자인 실력과 고급 프로그래밍 실력을 모두 갖춘 사람은 흔하지 않다. MVC 패턴은 두 가지 영역에 대한 개발을 분리할 수 있다.
② 같은 데이터에 대한 다른 표현이 종종 발생한다. MVC 패턴은 같은 데이터를 서로 다르게 보여지도록 디자인 할 수 있다.
③ 웹 기반 응용 프로그램은 비즈니스 로직 보다 사용자 인터페이스가 자주 바뀐다. (페이지의 리뉴얼이 일어날 경우 비즈니스 로직은 전혀 변화가 없는 경우가 허다하다) MVC 패턴은 비즈니스 로직의 변화 없이 사용자 인터페이스의 변화를 가능하게 해 준다.
④ 리치 클라이언트용 웹 응용 프로그램이 PDA용 웹 응용 프로그램으로 마이그레이션 될 경우, 사용자 인터페이스가 크게 변화한다. 이러한 장치 의존적인 작업이 일어날 경우, MVC 패턴은 비즈니스 로직의 변화 없이 작업을 완료할 수 있게 한다.
MVC 모델은 Model - View - Controller 3 가지 클래스로 역할을 구분하도록 프리젠테이션을 설계하는 기법이다. GoF의 디자인 패턴[1]에 의하면, MVC 패턴을 다음과 같이 설명한다.
“MVC는 세 가지 객체로 이루어진다. 모델은 응용 프로그램 객체이며, 뷰는 스크린에 모델을 디스플레이 하는 방법이며, 컨트롤러는 사용자 인터페이스가 사용자 입력에 반응하는 방법을 정의한다.”
MVC 패턴에서 얻을 수 있는 가장 핵심적인 장점은 뷰와 컨트롤러는 모델의 의존하지만 모델은 뷰와 컨트롤러에 의존하지 않는다는 것이다. 이런 장점으로 인해 실제 객체들이 존재하는 모델 계층의 클래스들이 프레젠테이션과 별도로 작성되고 테스트 될 수 있다.
ASP.NET 에서의 구현
사실상, ASP.NET은 전형적인 이벤트 드리븐 방식을 사용한다. ASP.NET은 HttpHandler 클래스가 전방에서 동작하여 모든 페이지들에 대한 요청을 처리하고 발생하는 이벤트를 처리하는 이벤트 지향적인 방법을 선택하고 있어 Front Controller나 Page Controller등의 향상된 설계 기법을 이미 내장하고 있다고 봐도 무방하다. ASP.NET에서 MVC의 구현은 HttpHandler 같은 컨트롤러의 구현과 별 상관없이 (혹은 그 존재를 모르더라도), ASP.NET이 지원하는 Code-Behind 기능을 사용하여 할 수 있게 된다. 모델이 뷰에 의존하지 않게 설계하는 것이 MVC의 목적이라고 한다면, Code-Behind의 사용으로 그러한 목적을 훌륭하게 달성할 수 있다.
다음 그림과 같은 페이지를 디자인 한다고 하자. 페이지는 Page_Load 이벤트 핸들러에서 책의 타입을 로드하여 드롭다운 리스트에 보여주고, 버튼의 이벤트에 반응하여 데이터그리드컨트롤에 바인딩한다.
ASP.NET에서 <그림 4>와 같은 페이지를 제작하는 것은 아주 다양한 방법으로 할 수 있다. 우선, 가장 쉬운 방법은 <코드 1> 과 같이 In-Line 코드를 쓰는 것이다. 모든 내용을 하나의 파일안에 써서 로직과 뷰를 단순히
