라이브러리
프로그래밍언어, 각종코드, 관련동향, 논문 등의 저장소
[기업 환경에 닷넷 적용하기] ④ 닷넷의 웹 프리젠테이션 패턴

[기업 환경에 닷넷 적용하기] ④ 닷넷의 웹 프리젠테이션 패턴

 

연재순서
1.제대로 된 컴포넌트를 위한 프리젠테이션 레이어 설계하기
2.비즈니스 로직 레이어 설계와 물리적 구현을 위한 필요 사항
3.엔터프라이즈 솔루션 패턴 해부하기
4.닷넷의 웹 프리젠테이션 패턴
5.닷넷 개발에서 UML과 케이스 툴의 사용

 

현재의 웹 프로그래밍 환경은 HTML 태그로 하이퍼 링크와 그림만을 입력하던 예전과는 판이하게 틀리다. 변화가 없는 HTML 페이지가 사용자와 상호 작용하여야 하는 경우가 발생하자 CGI (Common Gateway Script)가 등장했다. Perl 또는 C언어로 작성되는 CGI는 사용자의 입력에 따라서 동적인 페이지를 생성했다. 하지만 재 사용 가능한 코드를 쓰기가 거의 불가능에 가까웠고, GGI 프로그래밍은 복잡한 프로그래밍 환경을 만족시키지 못했다. 그 후에 등장한 프로그래밍 모델은 페이지 기반 개발이었다.

ASP또는 PHP로 대표되는 페이지 기반 개발은 여러 계층으로 동작하던 CGI의 복잡성을 줄여주었다. 하지만, 페이지가 갈수록 늘어나고 작성해야 하는 페이지의 수가 말도 못하게 늘어남에 따라 페이지 기반 개발 방식은 프레임워크 기반 방식으로 발전했다. 튼튼하게 제작된 프레임워크는 페이지에 발생하는 복잡함을 줄이는 대신 자신이 대신해 주었다. 프로그래머가 해야 하는 일은 줄어들었다.

사용자 삽입 이미지
<그림 1> 웹 프로그래밍 환경의 변화


프레임워크가 등장함에 따라 페이지를 어떻게 작성할 것인지에 대한 프로그래머의 선택권은 한없이 넓어졌다. 페이지 내에 스크립트를 그대로 유지하는 페이지 기반 프로그래밍 모델을 그대로 사용할 수도 있고, Java의 태그 라이브러리와 ASP.NET의 코드-비하인드를 사용하여 페이지 수준에서 프리젠테이션 로직과 페이지 로직을 구분할 수도 있게 되었다. 소프트웨어의 아키텍처를 정립하고 튼튼한 설계를 기반으로 개발을 시작하는 것은 과도한 복잡성과 중복성을 줄이기 위해서 인데, 웹 응용 프로그램 개발에서 사실상 가장 많이 중복되는 부분은 페이지에서 표현되는 프리젠테이션 계층의 로직들이다. 이런 중복된 내용을 비즈니스 로직 계층으로 옮겨 표현할 수도 있지만, 그렇게 처리한다면 비즈니스 로직 계층의 복잡도가 너무 증가하게 된다.

가장 좋은 방법은 프리젠테이션 계층의 컴포넌트들을 설계하고 이를 재 사용하기 위한 적당한 정도의 복잡성을 가지게 설계하는 것이다. 마이크로소프트의 Enterprise Solution Pattern using Microsoft.net에서는 그 “적당한” 복잡도에 대한 6가지의 질문을 준비하고 그 질문에 대한 대답으로 패턴을 제시한다.

사용자 삽입 이미지
<표 1>


위의 <표 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>는 웹 프리젠테이션 패턴의 패턴 클러스터이다. (패턴 클러스터에 대해서는 지난 달 연재를 살펴보기 바란다.)

사용자 삽입 이미지
<그림 2> 웹 프리젠테이션 패턴의 패턴 클러스터


MVC (Model-View-Controller) 패턴
해결책의 쌍으로서 MVC 패턴을 생각해보면 질문은 다음과 같다.


“개별적인 영역을 쉽게 수정하기 위해서 웹 응용 프로그램의 사용자 인터페이스 기능을 어떻게 모듈화 할 것인가?”


질문이 너무 추상적인 것 같이 느껴진다. 질문을 해설해보면 주로 다음과 같은 문제라고 생각할 수 있다.

① HTML 페이지를 설계하는 것과 비즈니스 로직을 설계하는 것은 거의 모든 경우에 다른 기술이 필요하다. 이는 웹 디자이너와 프로그래머의 고질적은 의견 대립을 발생시키는 문제이기도 하다. 빼어난 웹 디자인 실력과 고급 프로그래밍 실력을 모두 갖춘 사람은 흔하지 않다. MVC 패턴은 두 가지 영역에 대한 개발을 분리할 수 있다.

② 같은 데이터에 대한 다른 표현이 종종 발생한다. MVC 패턴은 같은 데이터를 서로 다르게 보여지도록 디자인 할 수 있다.

③ 웹 기반 응용 프로그램은 비즈니스 로직 보다 사용자 인터페이스가 자주 바뀐다. (페이지의 리뉴얼이 일어날 경우 비즈니스 로직은 전혀 변화가 없는 경우가 허다하다) MVC 패턴은 비즈니스 로직의 변화 없이 사용자 인터페이스의 변화를 가능하게 해 준다.

④ 리치 클라이언트용 웹 응용 프로그램이 PDA용 웹 응용 프로그램으로 마이그레이션 될 경우, 사용자 인터페이스가 크게 변화한다. 이러한 장치 의존적인 작업이 일어날 경우, MVC 패턴은 비즈니스 로직의 변화 없이 작업을 완료할 수 있게 한다.

MVC 모델은 Model - View - Controller 3 가지 클래스로 역할을 구분하도록 프리젠테이션을 설계하는 기법이다. GoF의 디자인 패턴[1]에 의하면, MVC 패턴을 다음과 같이 설명한다.


“MVC는 세 가지 객체로 이루어진다. 모델은 응용 프로그램 객체이며, 뷰는 스크린에 모델을 디스플레이 하는 방법이며, 컨트롤러는 사용자 인터페이스가 사용자 입력에 반응하는 방법을 정의한다.”


사용자 삽입 이미지
<그림 3> 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 이벤트 핸들러에서 책의 타입을 로드하여 드롭다운 리스트에 보여주고, 버튼의 이벤트에 반응하여 데이터그리드컨트롤에 바인딩한다.

사용자 삽입 이미지
<그림 4> 예제 페이지


ASP.NET에서 <그림 4>와 같은 페이지를 제작하는 것은 아주 다양한 방법으로 할 수 있다. 우선, 가장 쉬운 방법은 <코드 1> 과 같이 In-Line 코드를 쓰는 것이다. 모든 내용을 하나의 파일안에 써서 로직과 뷰를 단순히 <Script> 태그로 구분한다.

<코드 1> 한 파일에 세 역할을 모두 집어넣은 단일 ASP.NET 페이지
사용자 삽입 이미지

<%@ Import Namesace=”System.Data.SqlClient” %>
  <body>
    <Script Language=”C#” Runat=”Serve” />
    void Page_Load(object sender, EventArgs e) {
      // 데이터베이스에 연결하여 데이터를 반환받음
    }
    void btn_Click(object sender, EventArgs e) {
      // 버튼 클릭 이벤트에 반응하여 데이터를 반환받음
    }
    </Script>
    <form id="Solution" method="post" Runat="Server">
      <h3>Titles</h3>
      Select a Titles:<br>
      <asp:DropDownList id="titlesSelect" runat="Server" />
      <asp:Button Runat="Server" Text="Submit" id="Button1" name="Button1" />
      <p>
        <asp:DataGrid id="myDataGrid" Runat="Server" />
  </form>
  </P>
</body>
사용자 삽입 이미지

위 코드는 패턴에 있는 Model, View, Controller 세 가지 역할을 모두 담당한다. 다만, 구분하지 않을 뿐이다. View의 역할은 HTML로 표시된다. 페이지는 잘 동작하고, 독립적이며 직관적이다. 작은 응용 프로그램이거나 페이지가 자주 변경되지 않는 경우라면 아주 권장할 만한 생산성 뛰어나고 쉬운 개발 방법이라 할 수 있다. 하지만, 여러명이 동시에 작업을 진행하는 경우, (대표적으로 웹 디자이너와 프리젠테이션 로직 개발자가 같이 작업을 병행하는 경우)와 사용된 데이터 액세스 코드를 재 사용하고 싶은 경우, 위와 같은 설계라면 거의 작업이 불가능하다. 이런 문제에 당면했다면, Code-Behind를 사용하여 리팩토링 할 수 있다. Visual Studio.net을 사용하지 않았기 때문에, Page 지시문에서 CodeBehind 대신 Src를 사용했다.

<코드 2> Code-Behind 리팩토링 한 View 페이지 (.aspx 페이지)
사용자 삽입 이미지

<%@ Page language="c#" Src="CodeBehind.aspx.cs" AutoEventWireup="false" Inherits="CodeBehind1.CodeBehind" %>
<HTML>
  <HEAD>
    <title>Solution
  </HEAD>
  <body>
    <form id="Solution" method="post" Runat="Server">
      // 동일한 View 코드
  </body>
</HTML>
사용자 삽입 이미지


<코드 3> CodeBehind 리팩토링한 코드 비하인드 코드
사용자 삽입 이미지

using System;
using System.Data;
using System.Data.SqlClient;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace CodeBehind1
{
  public class CodeBehind : System.Web.UI.Page
  {
    protected System.Web.UI.WebControls.DropDownList titlesSelect;
    protected System.Web.UI.WebControls.Button Button1;
    protected System.Web.UI.WebControls.DataGrid myDataGrid;

    private void Page_Load(object sender, System.EventArgs e)
    {
      f (!Page.IsPostBack) {
        // 데이터베이스에 연결하여 데이터를 반환받음
      }
    }

  // OnInit 이벤트 핸들러 및 InitializeComponent() 메소드

  public void SubmitBtn_Click(object sender, System.EventArgs e)
  {
    // 버튼 클릭 이벤트에 반응하여 데이터를 반환받음
  }
  }
}
사용자 삽입 이미지

위 리팩토링에서 <코드 2>에는 WebForm 컨트롤들과 HTML 태그만이 존재하여 View 와 다른 역할들을 구분한다. <코드 3>에는 Model과 Controller 역할을 수행하는 코드들이 들어있다. 이렇게 설계된 페이지에서는 페이지가 데이터베이스에 액세스하기 위한 어떠한 코드들도 가지고 있지 않기 때문에 데이터베이스 코드가 변경된다거나 페이지의 디자인이 변경된다 하더라도 서로 간섭받지 않게 된다.

코드-비하인드 기능이 3-Tire 구조 아키텍처를 사용하기 위한 프리젠테이션 계층과 비즈니스 로직 계층을 강제 구분하는데 사용된다는 말이 있었는데, 그렇게 정확한 이야기는 아니다. ASP.NET의 코드-비하인드는 위에서 보듯이 View 역할과 다른 역할들을 구분할 수 있도록 하는데 주로 사용될 수 있다.

주어진 질문에서 해결되지 않은 것은 로직을 재 사용하는 것이다. 기술적으로는 Code-Behind 코드의 재 사용이 가능하지만 현실적으로는 거의 불가능하다. 특히 Visual Studio.net을 사용해서 이런 작업을 해본 경험이 있는 개발자라면 하나의 코드-비하인드 파일을 여러 개의 뷰 파일이 공유해 쓰는 것은 거의 불가능하다는 것을 알 것이다. 이 경우에 대한 답이 바로 MVC 패턴을 사용하는 것이다.

위의 코드-비하인드 리팩토링에서 뷰를 표현하는 aspx 페이지는 수정할 부분이 없다. <코드 3>의 코드-비하인드 페이지가 모델과 컨트롤러 두 가지 역할을 담당하는데, 모델과 컨트롤러의 역할을 구분해 주어 모델의 코드를 재 사용할 수 있게 하는 것이다.

데이터베이스에 액세스하는 로직을 가지는 모델 클래스를 생성한다.

<코드 4> MVC 리팩토링에서 Model
사용자 삽입 이미지
using System;
using System.Data;
using System.Data.SqlClient;

public class Model {
  public static DataSet GetTypes() {
    // 데이터베이스에 액세스하여 책의 타입 정보를 데이터셋으로 반환한다.
  }

  public static DataSet GetTitles(string typeID) {
    // 데이터베이스에 액세스하여 타입에 해당하는 책 정보를 반환한다.
  }
}
사용자 삽입 이미지

Page 클래스를 상속하는 CodeBehind 클래스는 다음과 같이 역할이 수정된다.

<코드 5> MVC 리팩토링에서 Controller
사용자 삽입 이미지

public class CodeBehind : System.Web.UI.Page {
  protected System.Web.UI.WebControls.DropDownList titlesSelect;
  protected System.Web.UI.WebControls.Button Button1;
  protected System.Web.UI.WebControls.DataGrid myDataGrid;

  private void Page_Load(object sender, System.EventArgs e) {
    if (!Page.IsPostBack) {
// 모델 클래스의 GetTypes() 메소드 호출 결과를 컨트롤에 바인딩
    }
  }

    // OnInit 이벤트 핸들러 및 InitializeComponent() 메소드

  public void SubmitBtn_Click(object sender, System.EventArgs e)
  {
    // 모델 클래스의 GetTitles () 메소드 호출 결과를 컨트롤에 바인딩
  }
}
사용자 삽입 이미지

ASP.NET에서 MVC 모델을 고려하여 설계하면 다음과 같은 장점들을 얻는다.

  • 페이지 간의 의존성이 감소한다.

  • 메소드의 재 사용성이 증가한다.

  • 동시 작업을 진행할 수 있다.

  • 테스트가 용이하다.

    하지만 모든 장점에는 단점이 따라오는 법이다. MVC의 단점은 파일과 코드가 추가된다는 것이다. 필자가 참여했던 모 프로젝트에서, 경험 있는 닷넷 개발자가 다음과 같이 이야기 하는 것을 들은적이 있다. 당시 필자는 어차피 디자이너가 닷넷을 잘 모르니 M-VC로 프로젝트를 진행하는 것이 차라리 효율적이라고 주장하고 있었다.

    “제가 전에 참여했던 닷넷 프로젝트에서, VS.NET을 사용했었는데, 디자이너에게 1주일쯤 닷넷을 가르치고 Code-Behind로 개발하는 것이 아주 효율적이었습니다”

    필자도 수긍을 했고, 디자이너도 닷넷을 배우겠다고 자청하여 1주일쯤 디자이너에게 WebForm 사용법을 가르친 후 (DataGrid 컨트롤과 DataList 컨트롤의 사용법을 익히느라고 디자이너가 꽤 고생을 하긴 했다) VS.net을 사용하여 MVC 패턴을 적용하여 진행된 프로젝트는 꽤 성공적으로 진행되었다. 디자이너는 aspx 작업을 하고, 개발자는 컨트롤의 이름만 알면 동시 작업을 진행할 수 있었다. 기업형 응용 프로그램 개발에서 MVC 패턴의 장점을 잘 보여주는 단적인 예였다.

    Page Controller
    패턴 클러스터에서 Page Controller 패턴은 MVC 패턴과 같은 레벨에 놓여 있다. Page Controller 패턴은 MVC 패턴에 기반한다. Page Controller 패턴을 질문 ? 해결책의 쌍으로서 Page Controller 패턴을 생각해보면 질문은 다음과 같다.

    “코드를 복사하지 않으면서 재 사용이 가능하고 융통성있는 약간 복잡한 웹 응용 프로그램을 어떻게 작성할 것인가?”

    역시 질문이 너무 추상적이다. 질문을 해설해보면 주로 다음과 같은 문제라고 생각할 수 있다.

    ① 예를 들면, 게시판에 글을 쓰는 동작을 하고 나면 고쳐진 게시판의 리스트 페이지로 이동한다. 웹 기반의 전자메일 응용 프로그램에서 메일을 발송하고 나면 고쳐진 받은 편지함 페이지로 이동한다. 이러한 이동은 거의 정적이고, 같은 방식으로 동작한다. 세부적인 동작은 틀리지만, 사용자의 행위는 동일하다. 사용자의 행위가 동일함에도 불구하고 여러 개의 컨트롤러에 개별적인 코드를 써서 MVC 패턴의 단점인 복잡성을 그대로 둘 것인가?

    ② MVC 패턴의 단점중의 하나는 파일의 개수가 증가하여 여러 개의 파일을 따로 컨트롤러를 따로 테스트 해야 한다는 것이다. 여러 개의 사용자 인터페이스를 동일한 타입의 컨트롤러가 관리한다면 테스트가 훨씬 용이해 질 수 있다.

    ③ ASP.NET의 이벤트 모델은 고정되어 있다. 따라서, 거의 모든 페이지가 유사한 방식으로 렌더링 된다. 사용자 인증을 검증하고, 쿼리 문자열로부터 Request 정보를 얻어내고 같은 헤더와 꼬리말을 사용한다. 이러한 작업을 하나로 묶어 복잡성을 줄일 수 있을 것인가?

    이런 질문의 해결책으로 Page Controller 패턴이 제시된다. 만약, 다음과 같은 상황에 직면했다고 생각해 보자. 웹 응용 프로그램이 7개의 게시판을 가지고 있다. 게시판은 공지사항, 뉴스, QnA, 공개 게시판 등인데 동작하는 방식은 완전히 같다. 게시판의 디자인은 수시로 변하는 등의 이유로 MVC 패턴을 응용하여 설계 하였다.

    그렇다면, 각 게시판의 글 쓰기 페이지와 리스트 보기 페이지 등의 동작은 완전히 같다. 이런경우, 각 게시판별로 각각의 뷰 페이지와 컨트롤러를 작성하는 것은 부담이 되고 또한 테스트 하기 곤란해 진다. (물론, 하나의 페이지가 모든 게시판을 처리하도록 작성할 수 있으나, 웹 페이지 디자인 등의 문제로 그렇게 처리하기가 곤란한 상황이라고 가정하자) 이런 경우, Page Controller 패턴의 사용을 고려해 볼 수 있다는 이야기다.

    모든 게시판에서 글 수정하기 페이지를 작성할 때, 페이지의 모든 컨트롤러는 다음과 같은 기능들을 구현한다.

    <코드 6> Controller
    사용자 삽입 이미지

    public class Modify_Article : System.Web.UI.Page {
      // 전역변수 (WebForm 컨트롤들)
      int no;

      private void Page_Load(object sender, System.EventArgs e) {
        // 쿼리스트링으로 전달된 값 처리
        no = Int32.Parse(Request.Params["no"].ToString());
        GetArticle(no);
      }

      override protected void OnInit(EventArgs e) { ... }
      private void InitializeComponent() { ... }

      private void GetArticle(int no) {
        // 글을 가져와서 컨트롤에 바인딩
      }

      private void Modify_Article(object sender, System.EventArgs e) {
        Model.Modify_Article(no); // 글 수정
        Response.Redirect("ListPage.aspx"); // 리스트 페이지로 이동
      }
    }
    사용자 삽입 이미지

    위와 같이 같은 방식으로 동작하는 컨트롤러를 여러 개 작성하는 것은 좋지 않은 해결책이 된다. 이를 위해서, 공통적인 동작을 하는 페이지 컨트롤러를 작성하고, 같은 동작을 하는 컨트롤러를 집중화 해서 요청에 대한 중앙 집중적인 처리를 담당할 수 있도록 하는 것이 유리해진다. 개선된 컨트롤러들은 <그림 5>와 같은 방식으로 설계될 수 있다.

    사용자 삽입 이미지
    <그림 5> Page Controller 패턴을 이용한 설계 개선

    <그림 5>의 클래스 다이어그램에서 BoardController 클래스는 다음과 같은 코드로 구현된다.

    <코드 6> BoardController 클래스의 구현
    사용자 삽입 이미지

    public class BoardController : System.Web.UI.Page {
      protected void Page_Load(object sender, System.EventArgs e) {
        no = Int32.Parse(Request.Params["no"].ToString());
        GetArticle(no);
      }

      #region Web Form 디자이너에서 생성한 코드
      override protected void OnInit(EventArgs e) {
        InitializeComponent();
        base.OnInit(e);
      }

      private void InitializeComponent() {
        this.Modify_Article.Click +=
        new System.EventHandler(this.Modify_Article_Click);
        this.Load += new System.EventHandler(this.Page_Load);
      }
      protected virtual void GetArticle(int no) { }

      protected virtual void Modify_Article_Click(object sender, System.EventArgs e){}
    }
    사용자 삽입 이미지

    <그림 5>의 클래스 다이어그램에서와 같이, NoticeModify.aspx 페이지에 작성된 뷰와 모델을 컨트롤하는 컨트롤러 NoticeModify 클래스는 공통적인 구현을 포함하는 BoardController를 상속하고, GetArticle() 메소드와 Modify_Article_Click() 이벤트 핸들러를 오버라이드 하는 간단한 코드만으로 전체 컨트롤을 중앙 집중화 할 수 있다. BoardController 클래스의 Page_Load 이벤트 핸들러가 GoF 디자인 패턴[1]의 Template Method 역할을 하는 것이다. GoF의 디자인 패턴에서는, Template Medhod가 추상 메소드로 구현되고 기본 클래스가 추상 클래스이지만 ASP.NET에서는 Page를 상속하는 클래스가 추상 메소드가 될 수 없으므로, 가상 메소드로 구현하여야 한다.

    <코드 7> NoticeModify 컨트롤러
    사용자 삽입 이미지

    public class NoticeModify : BoardController {
      protected override void GetArticle(int no) {
        // Notice 모델에서 글을 가져와서 컨트롤에 바인딩한다.
      }

      protected override void Modify_Article_Click(object sender, System.EventArgs e) {
        // Notice 모델에 액세스하여 글을 업데이트 한다.
      }
    }
    사용자 삽입 이미지

    Page Controller 패턴을 사용하면 다음과 같은 장점을 얻을 수 있다.
  • 간단히 구현할 수 있다. 전체 컨트롤러를 중앙 집중화하는 Front Controller와는 달리 Page Controller 패턴은 하나의 동적인 페이지가 하나의 컨트롤러에 의해서 처리되므로, 간단함을 유지할 수 있다. 그러므로 Page Controller는 어느 정도 복잡한 웹 응용 프로그램에 적당하다.

  • ASP.NET이 제공하는 컨트롤러를 그대로 활용하여 일관된 개발 방향을 유지할 수 있다. 실저적으로 ASP.NET은 HttpHandler에 컨트롤러를 구현하고 있으므로, 기본적인 컨트롤러를 사용할 수 있다.

  • Template Method 패턴을 활용하므로 공통적인 구현에 대한 재사용성이 증가한다. 또한, 객체지향의 상속성을 이용하므로 쉽게 확장할 수 있다. 헬퍼 클래스를 사용하여 기능을 확장할 수도 있다.

    당연히, 단점도 있는법, Page Controller 패턴은 다음과 같은 단점을 가진다.

  • 객체 지향의 오랜 논란인 상속 트리가 깊어진다는 치명적인 단점을 가지고 있다.

  • 복잡한 응용 프로그램에 사용하면 감당할 수 없을 정도로 꼬인다는 단점이 있다.

    이런 문제를 해결하기 위해서, 전체 컨트롤러를 중앙 집중화 하는 Front-Controller 패턴을 사용할 수 있다. Front Controller 패턴과 Observer 패턴등은 조금 복잡한 클래스 구조를 가지게 되므로 다음 연재에서 닷넷 개발에서 UML과 케이스 툴을 사용하는 방법과 함께 생각해 보도록 하겠다.

    마치면서
    얼마 전, 마이크로소프트 리서치에서 F#이라는 새 언어를 본 적이 있다. (새 언어가 아니고 이전부터 연구되던 언어이긴 하다) 필자는 대학원 시절, 석사학위 논문 주제로 C#에서 Generics의 구현을 연구한 적이 있는데, 그때 많이 참조한 부분이기도 하다. F#은 ML을 기반으로 작성된 함수형 언어인데, 닷넷 환경에서는 COM을 위한 스크립트 언어 정도로 쓰이면 아주 강력할 것 같다는 느낌을 받았다.

    같이 근무하는 다른 연구원님들과 그런 이야기를 하다가, F#이라는 언어가 쓸모 있다고 해도 과연 C#이나 VB같은 언어들이 익숙한 개발자들에게 받아들여 질 수 있을까에 대해서 생각했다. 필자의 스승이기도 한 책임 연구원님은 특유의 어투로 “안 사용하면 말고.. 쓰고 싶으면 쓰고…” 라고 이야기 했지만 필자는 좋은 것이 있으면 반드시 사용해서 더 좋은, 제대로 된 응용 프로그램을 만들어야 한다는 쪽이다.

    개발자들도 의사고시 같은 시험이 생겨서 인턴, 레지던트 과정을 거쳐서 개발자 개업도 하고 하는 환경이 와야 우리나라 IT가 제대로 될 것 같다는 우스갯 소리도 했다. 새로운 피쳐가 등장하고 새로운 기법이 등장하였다고 반드시 그것을 사용해야 한다는 법은 없다. 하지만, 개발자들은 유수의 기업과 뛰어난 개발자 / 학자들이 연구한 산출물을 연구해 봐야 한다는 의무감을 가져야 한다고 생각한다. Enterprise Solution Pattern같은 뛰어난 결과들을 실제 개발에 응용하지는 않더라도 이러한 기법이 있더라 하는 것을 알고만 있는 것으로도 훨씬 더 훌륭한 구조를 가지는 뛰어난 프로그램을 작성할 수 있는 법이다.

    허준 같은 의원들의 의무가 환자들을 치료하고 보살피는 것이라면, 개발자들의 의무는 좋은 프로그램을 작성하는 것이다. 날로 떨어지는 개발자들에 대한 대우와 바쁜 일정이 그런 기본적인 의무감 마저 상실하게 하는 것 같아 씁쓸하긴 하다.@

    * 이 기사는 ZDNet Korea의 제휴매체인마이크로소프트웨어에 게재된 내용입니다.
  •  

    김상훈 (동명정보대학 정보기술원 연구원)

    2005/09/07

     

    사용자 삽입 이미지

     

     

     

     

    원문 :http://www.zdnet.co.kr/builder/dev/dotnet/0,39031607,39139339,00.htm

      Comments,     Trackbacks