ASP.NET 프레젠테이션 패턴

ASP.NET 프레젠테이션 패턴

Dino Esposito

이 칼럼은 ASP.NET MVC Framework 시험판 버전을 기준으로 합니다. 모든 정보는 변경될 수 있습니다.

 목차

ASP.NET 이벤트 처리기의 내부 
원래의 MVC 패턴 
Model2: 웹 변형 MVC 
ASP.NET MVC Framework 및 수동 MVC 비교 
MVP 패턴 
페이지 컨트롤러 패턴 

계층 웹 응용 프로그램에서 프레젠테이션 계층은 탐색 논리, 비즈니스 논리 및 데이터 액세스만큼이나 중요합니다. 프레젠테이션 계층(주로 프레젠테이션 논리)을 UI 기술 및 플랫폼과는 독립적으로 유지하도록 노력해야 하지만 말처럼 쉬운 일은 아닙니다. 여기에 디자인 패턴이 도움이 됩니다.

이달의 칼럼에서는 ASP.NET 프레젠테이션 계층을 작성하기 위한 몇 가지 디자인 패턴을 살펴보겠습니다. UI 대상의 모든 패턴의 기본인 MVC(Model-View-Controller) 패턴으로부터 시작하여 ASP.NET을 초월하여 ASP.NET MVC Framework에 대한 적용 가능성을 살펴보겠습니다.

ASP.NET 이벤트 처리기의 내부

ASP.NET 프레젠테이션 계층은 대부분 HTTP 런타임 환경을 통해 조율되는 .aspx 페이지로 구성됩니다. 일반적인 .aspx 페이지는 단추 클릭이나 목록 선택과 같은 특정한 사용자의 동작에 대한 반응으로 HTTP 요청을 수행합니다. ASP.NET Web Forms 프로그래밍에서 이러한 이벤트는 일반적으로 페이지의 코드 숨김 클래스에 작성하는 메서드, 즉 이벤트 처리기에 의해 처리됩니다. 사용자 동작과 시스템의 반응 사이에 직접적인 연결이 있는 것처럼 보이기도 합니다. 데스크톱 응용 프로그램의 경우에는 이것이 사실이지만 ASP.NET의 경우에는 그렇지 않습니다.

ASP.NET에서는 AJAX의 사용 여부에 관계없이 사용자의 클릭과 업데이트된 페이지의 표시 사이의 시간에는 많은 일이 일어납니다. 그러나 ASP.NET MVC Framework를 사용하여 작성한 ASP.NET 응용 프로그램에서는 정보의 흐름이 더 짧습니다.

단추 클릭 이벤트에 대해 고려해 보겠습니다. 개발자는 Button 컨트롤의 Click 이벤트 처리기에 코드를 작성하여 이 이벤트를 처리합니다. 코드는 다음과 같이 페이지의 코드 숨김에 배치됩니다.

void Button1_Click(object sender, EventArgs e)
{
    // Perform any required action
}

여기에 필요한 동작을 위한 모든 코드를 넣거나 개체가 공개하는 정적 또는 인스턴스 메서드에 이러한 모든 코드를 그룹화할 수 있습니다.

void Button1_Click(object sender, EventArgs e)
{
    // Static method bound to the user action
    ActionManager.Button1Clicked();
}

사용자의 작업에 반응하는 코드를 컨트롤러나 동작에 구성할 수도 있습니다.

   void Button1_Click(object sender, EventArgs e)
   {
       // Static method bound to the user action
       ThisPageController controller = new    
       ThisPageController(); 
       controller.Button1Clicked();
   }

여기에서는 각 페이지가 자체 컨트롤러 구성 요소를 가지며 각 컨트롤러가 가능한 사용자 작업에 논리적으로 바인딩된 공용 메서드의 목록을 가진다고 가정합니다.

컨트롤러에 페이지의 상태를 알리고 새 보기를 생성하려면 어떻게 해야 할까요? 사용자가 단추를 클릭하면 ASP.NET 런타임이 해당하는 HTTP 요청을 수신하고 처리한 후에 서버에서 Button1_Click이 호출됩니다. Button1_Click 메서드는 System.Web.UI.Page로부터 파생된 클래스에 의해 공개됩니다. 이 클래스는 UI 컨트롤에 액세스할 수 있습니다.

여기에서 컨트롤러 용법에 대한 간단한 변경으로 컨트롤러가 페이지의 모든 공용 요소에 액세스할 수 있게 됩니다.

void Button1_Click(object sender, EventArgs e)
{
    // Static method bound to the user action
    ThisPageController controller = new ThisPageController(this); 
    controller.Button1Clicked();
}

컨트롤러의 용법은 이제 현재 ASP.NET 페이지에 대한 참조, 즉 뷰를 받습니다. 컨트롤러 메서드는 자체 작업을 수행한 다음 서버 컨트롤을 업데이트합니다. ASP.NET의 표준 페이지 수명 주기에서는 나머지 작업을 수행하고 브라우저를 위해 HTML을 생성합니다.

페이지 수명 주기

그림 1에는 페이지 수명 주기의 주요 단계가 나와 있습니다. ASP.NET 요청이 웹 서버로 전달되고 서비스를 제공할 HTTP 처리기가 발견되면 그림에 나와 있는 단계가 수행됩니다. 여기에서 볼 수 있듯이 간단한 단추 클릭을 위한 코드는 전체 ASP.NET 인프라에서 극히 일부입니다. 페이지 수명 주기는 ASP.NET 런타임이 각 요청에 서비스를 제공하기 위해 실행하는 작업의 일부를 나타낸다는 것을 확인할 수 있을 것입니다.

그림 1 ASP.NET 페이지 수명 주기

ASP.NET 런타임이 요청된 URL의 예상되는 동작을 포함하는 Page 클래스의 인스턴스를 만들어야 Button1_Click의 코드가 실행될 수 있습니다. Page 클래스는그림 1에 나와 있는 단계에 따라 요청을 처리하며 적절한 부분에 여러분의 이벤트 처리기를 사용합니다.

컨트롤러 클래스의 Button1Clicked 메서드에서는 보통 코드 숨김 이벤트 처리기에서 사용하는 것과 같은 구문으로 페이지에 있는 모든 컨트롤에 액세스할 수 있습니다. 그러나 참조 UI 컨트롤(예: TextBox1)은 Page 클래스의 공용 멤버가 아닙니다. 컨트롤러에서 이를 액세스할 수 있도록 하려면 어떻게 해야 할까요? 컨트롤러 내에서 조작하려는 UI 컨트롤에 대한 공용 속성을 포함하는 코드 숨김 클래스에 사용자 지정 인터페이스를 구현할 수 있습니다. 다음은 그 예입니다.

public interface IThisPageView
{
    TextBox TextBox1Property; 
    ...
}

// In the codebehind class
public TextBox TextBox1Property
{
    get {return TextBox1;}
}

그림 2에는 샘플 컨트롤러의 예가 나와 있습니다. Button1Clicked에서는 일반적인 ASP.NET Web Forms 프로그래밍을 수행하고 서버 컨트롤의 상태를 업데이트하여 다음 뷰를 결정할 수 있습니다. 페이지의 논리는 이제 별도의 클래스에 캡슐화되어 페이지와 별도로 개발할 수 있습니다.

 그림 2 페이지의 컨트롤러로 작동하는 샘플 클래스

public class ThisPageController
{
   protected IThisPageView thePage;

   public ThisPageController(IThisPageView page)
   {
      thePage = page;
   }

   public void Button1Clicked()  
   {
       // Get the text currently stored in control TextBox1
       string text = thePage.TextBox1Property.Text;

       // Do something: i.e., turn to upper case
       string newText = text.ToUpper();

       // Update the text in control TextBox1
       _thePage.TextBox1Property.Text = newText;
   }
}

그러나 이 솔루션은 페이지의 컨트롤과 여전히 밀결합되어 있습니다. MVP(Model-View-Presenter) 패턴을 참조하여 개선 방안을 고려해 보기로 하고 먼저 MVC와 MVP 패턴의 기본적인 내용을 다시 살펴보겠습니다.

원래의 MVC 패턴

MVC 패턴은 포괄적이고 자율적인 프런트 엔드에서 벗어나기 위해 1979년에 고안되었습니다. 자율적인 뷰는 콘텐츠를 표시하고 뷰에 대한 상태 정보를 관리하며 처음부터 끝까지 모든 사용자 동작을 처리하는 모든 논리가 통합되어 있는 클래스입니다.

다음 코드 조각은 자율적인 뷰의 기반을 보여 줍니다.

   void Button1_Click(object sender, EventArgs e)
   {
       // Perform any required action. All the code you 
       // need to handle the event goes here. A page 
       // built in this way is an autonomous view.
       // MVC fights autonomous views.
   }

이러한 일체식 뷰에서는 기반 계층에서 분리하여 테스트 가능한 프레젠테이션 계층을 만들기가 어렵습니다. SoC(Separation of Concern)의 개념을 도입하면 다양한 기능을 한데 혼합하는 것이 아니라 자체 계층에 유지할 수 있으므로 구성 요소의 결합은 완화하고 응집은 강화하는 올바른 조합을 달성할 수 있습니다. 게다가 SoC를 사용하면 다음 차례의 페이지를 결정하는 탐색 워크플로를 구현하기가 수월합니다.

MVC 방식을 설명하는 원래 논문("How to Use Model-View-Controller")을 온라인에서 볼 수 있습니다. 아직 논문을 읽어 보지 않았다면 MVC 철학에 대해 익숙하지 않더라도 한번 읽어 보기를 권장합니다. 현재는 MVC가 프레젠테이션 계층을 작성하기 위한 패턴으로 인식되고 있지만 처음에는 완전한 응용 프로그램을 작성하는 방법으로 고안되었습니다. 이러한 관점에서 살펴보면 도움이 될 것입니다.

MVC는 설계자에게 구현 세부 사항에 대한 재량권을 부여하는 느슨하게 정의된 패턴입니다. 이것이 MVC에 많은 변형이 존재하는 이유일 것입니다.

MVC는 응용 프로그램을 모델, 뷰, 그리고 컨트롤러의 세 부분으로 나눕니다. 모델은 응용 프로그램 데이터를 참조하고 응용 프로그램의 기능을 관리하며 상태 변화를 뷰에 알려 줍니다. 뷰는 사용자에게 표시되는 콘텐츠에 관여합니다. 마지막으로 컨트롤러는 사용자의 동작을 모델의 작업에 매핑하고 현재 뷰를 업데이트하거나 다음 뷰를 선택합니다. 이러한 세 주역을 종종 MVC 3인조라고 합니다. 그림 3에서는 그래픽을 통한 자율적인 뷰와 MVC 응용 프로그램 간의 비교가 나와 있습니다.

그림 3 자율적인 뷰와 MVC

MVC에서는 사용자가 뷰와 상호 작용하면 뷰가 단추 클릭과 같은 동작을 캡처하고 컨트롤러로 전달합니다. 컨트롤러는 무엇을 할지 결정하고 모델과의 상호 작용을 통해 이 작업을 수행합니다. 모델은 기본적으로 비즈니스 계층에 약간의 기능을 추가한 것입니다. 특히 모델은 UI 업데이트가 필요할 수 있는 변경을 뷰에 알립니다.

모델은 뷰의 세부적인 부분은 전혀 모르지만 모델과 뷰 사이에는 "관찰자" 관계가 있습니다. 다른 말로 하면 뷰는 모델에 대한 참조를 보유하며 변경에 대한 알림을 받기 위해 모델에 자신을 등록합니다. 알림을 받으면 뷰는 모델에서 최신 데이터를 얻고 UI를 업데이트합니다. 그림 4에는 MVC 상호 작용의 순서 다이어그램이 나와 있습니다. 일부 MVC 구현에서는 변경을 뷰에 알리는 역할을 컨트롤러가 수행합니다.

그림 4 표준 MVC 상호 작용 (더 크게 보려면 이미지를 클릭하십시오.)

Model2: 웹 변형 MVC

MVC는 데스크톱 응용 프로그램을 위해 고안되었지만 비교적 느슨한 구성 덕분에 웹에도 수월하게 적용할 수 있습니다. 웹에 맞게 변형된 MVC 패턴 중 잘 알려진 것으로 Model2가 있습니다. Model2는 현재의 ASP.NET MVC Framework에 중요한 단서를 제공한 역사적인 패턴이기도 합니다.

Model2 패턴은 브라우저를 통해 뷰를 사용자에게 공개합니다. 사용자의 작업은 브라우저에 의해 캡처되고 새로운 HTTP 요청으로 변환됩니다. 이러한 방법으로 요청이 브라우저로부터 웹 서버 내에 위치한 프런트 컨트롤러라고 하는 특수한 구성 요소로 전달됩니다. 프런트 컨트롤러는 웹 응용 프로그램에 대한 모든 요청을 조율합니다.

ASP.NET에서 프런트 컨트롤러는 URL 라우팅 HTTP 모델의 형태입니다. HTTP 모듈은 요청을 캡처하고 요청한 작업이 수행될 수 있도록 적절한 컨트롤러로 요청을 라우팅합니다. 작업 메서드가 반환되면 컨트롤러는 새 UI를 위해 데이터를 새로 고치고 전달하도록 뷰에 지시합니다. 그러면 뷰의 출력은 프런트 컨트롤러 HTTP 모듈에 의해 캡처되고 브라우저로 전달됩니다.

그림 5에는 일반적 Model2 상호 작용의 순서 다이어그램이 나와 있습니다. 다이어그램에는 일반적인 단계만 나와 있습니다. 예를 들어 패턴의 ASP.NET MVC 구현에서 URL 라우팅 구성 요소는 컨트롤러 사용 외에 약간의 추가 작업을 수행합니다.

그림 5 ASP.NET MVC Framework에서의 Model2 상호 작용 (더 크게 보려면 이미지를 클릭하십시오.)

원래 MVC와 Model2 사이에는 몇 가지 차이점이 있습니다. 원래 MVC 구성에서 앞서 언급한 "관찰자" 관계에 바탕을 두는 뷰와 모델 간의 연결이 없습니다. 또한 사용자의 작업이 뷰에 의해 캡처되고 처리되지 않습니다. 컨트롤러가 뷰를 렌더링하고 명시적으로 표시 데이터를 여기에 전달합니다.

ASP.NET에서 MVC에 대해 이야기할 때는 이 칼럼의 앞부분에서 간단하게 설명한 것처럼 Model2를 의미하는 것인지 또는 MVC의 수동 구현을 의미하는 것인지 명확하게 지정해야 합니다. 자세한 내용은 MSDN Magazine 기사(ASP.NET MVC Framework)를 참조하십시오.

ASP.NET MVC Framework 및 수동 MVC 비교

ASP.NET MVC Framework를 사용하는 것과 여러분이 직접 MVC 패턴의 구현을 운영하여 각 페이지(또는 페이지의 그룹)에 대한 컨트롤러 클래스를 작성하는 것의 차이는 무엇일까요? SoC의 관점에서는 중요한 차이점이 없습니다. 두 경우 모두 비즈니스나 서비스 계층에 대한 게이트웨이를 나타내는 뷰와 모델로부터 깔끔하게 분리된 컨트롤러 클래스를 사용할 수 있습니다.

테스트 용이성 측면에서는 뷰와 모델 간에 적용되는 깔끔한 분리와 매우 간소한 뷰 덕분에 원래 구성의 MVC 패턴보다는 Model2 패턴이 선호됩니다. 이러한 측면만으로도 ASP.NET MVC Framework용으로 작성한 코드가 테스트하는 데 훨씬 효과적입니다. 게다가 Model2에서는 뷰와 컨트롤러 간에 설정할 수 있는 일종의 느슨한 계약이 있습니다. ASP.NET MVC Framework에서 이 계약은 ViewData 컨테이너 개체 또는 더 나아가 뷰 클래스의 ViewPage<T> 기본 클래스에 의해 제공됩니다.

ASP.NET Web Forms와 비교하면 요청된 작업을 실행하는 데 있어 Model2 구현이 더 빠릅니다. Model2 구현에서는 HTTP 요청을 처리하고 컨트롤러를 호출할 구성 요소만 있으면 됩니다. 동적으로 페이지 클래스를 만들 필요가 없으며 컨트롤러에 대한 조회는 Web Forms 시나리오에서 HTTP 처리기를 조회하는 것에 비해 훨씬 단순한 알고리즘에 기반을 둡니다. 비슷하게 페이지 수명 주기, viewstate 또는 서버 컨트롤이 필요 없습니다. Model2 구현에서는 ASP.NET MVC Framework와 마찬가지로 훨씬 민첩한 런타임 환경을 사용할 수 있습니다. 자세한 내용은 살펴보겠습니다.

Web Forms 프로그래밍 모델을 기반으로 구현된 MVC 시나리오에서 사용자가 취하는 모든 동작은 HTTP 포스트 발생으로 이어집니다. 웹 서버는 이러한 요청을 캡처하고 이를 페이지 클래스로 매핑합니다. 페이지 클래스는 그림 1에 나와 있는 것과 같은 자체 수명 주기를 거칩니다. 그리고 올바른 컨트롤러를 알아내 다음 메서드를 호출합니다. 메서드를 실행하면 모델이 수정됩니다. 페이지 수명 주기의 남은 부분은 뷰를 새로 고치는 과정을 수행합니다.

ASP.NET MVC Framework로 구현한 Model2 시나리오에서는 다음 뷰가 생성되는 프로세스가 훨씬 간단합니다. URL 라우팅 모듈은 URL을 구문 분석하고 사용할 컨트롤러에서 이를 결정한 다음 이에 대해 작업을 호출합니다. 컨트롤러는 새 뷰에 대한 새 데이터를 수집하고 이 정보를 전달합니다. 뷰는 약간의 HTML을 구성하고 캡처된 요청에 대한 응답으로 이를 브라우저에 반환합니다. 뷰는 근본적으로 테스트가 필요 없는 수동적인 대상이며 컨트롤러에 테스트 노력을 집중해야 합니다.

Model2는 응용 프로그램의 테스트 용이성을 개선할 수 있는 훌륭한 대안입니다. 그러나 세션, 캐시, 그리고 서버 컨트롤을 지원하는 Web Forms 런타임 환경이 필요하거나 심지어 MVC 패턴에서 제공되는 viewstate가 필요한 경우에는 어떻게 해야 할까요? SoC와 테스트 용이성을 완전히 포기해야 할까요? 그렇지는 않습니다. 앞부분에서 언급한 MVC의 변형인 MVP 패턴을 선택하면 됩니다. 이 패턴은 임시 런타임을 요구하지 않고 웹 응용 프로그램에 적용됩니다.

MVP 패턴

원래 구성의 MVC에는 뷰를 업데이트하는 메커니즘에 한 가지 핵심적인 약점이 있습니다. 그림 4에 나오는 정보의 흐름을 관찰하면 뷰는 사용자 동작에 대한 통신을 컨트롤러와 수행하지만 변경에 대한 알림은 모델로부터 받는다는 것을 알 수 있습니다. 그리고 업데이트된 데이터를 가져오고 자체를 새로 고치기 위해 모델에 대한 세부적인 지식을 활용해야 합니다. MVP는 3인조의 요소를 보다 명확하게 분리하는 MVC의 변형입니다. 그림 6에서는 MVP 모델 주역 간의 일반적인 상호 작용이 나와 있습니다.

그림 6 MVP 패턴 작동 예 (더 크게 보려면 이미지를 클릭하십시오.)

MVP에서 뷰는 사용자 입력을 프레젠터에 전달하며 프레젠터로부터 업데이트를 위한 최신 데이터를 받습니다. 프레젠터는 모델과 상호 작용하여 요청에 대한 서비스를 제공합니다.

원래의 MVC에는 뷰가 어떤 데이터를 필요로 하는지 기술하는 명시적인 계약이 없습니다. MVC에서 뷰는 모델에 대한 참조를 보유하며 자체 논리를 실행하여 필요한 데이터를 선택하고 이를 UI 요소로 메시지로 전송합니다. 이러한 논리를 가지고 있기 때문에 뷰는 테스트 목적에서는 수동적인 대상으로 볼 수 없습니다. 또한 뷰는 어느 정도 수준까지 기본 UI 플랫폼에 의존합니다.

MVP에서 프레젠터는 기본적으로 사용자와 응용 프로그램 간의 중재자입니다. 프레젠터는 뷰를 렌더링하고 모델과 상호 작용할 능력을 가집니다. 결과적으로 대부분의 프레젠테이션 논리는 프레젠터 내에 있게 됩니다. 프레젠터는 UI가 없는 일반 클래스이므로 기본적으로 테스트하기는 수월합니다. 2006년 8월 MSDN Magazine Design Patterns 칼럼에서 ASP.NET 기반의 실용적인 MVP 패턴 구현을 볼 수 있습니다. MVP는 ASP.NET 관련 응용 프로그램 블록의 컬렉션인 Microsoft Web Client Software Factory에서 기본적으로 지원됩니다. MVP QuickStart는 MSDN을 통해 제공됩니다.

MVP는 Model2와는 달리 범용적인 UI 패턴이며 웹 전용으로 디자인되지 않았습니다. Model2(ASP.NET MVC Framework)와 MVP는 거의 동일합니다. 흥미로운 것은 두 가지 모두 원래부터 범용 패턴으로 디자인되지는 않았다는 것입니다.

기술적으로 말해 Model2와 MVP 간의 차이점은 컨트롤러(MVP에서는 프레젠터라고 부름)와 뷰 간의 계약이 유일합니다. 계약은 Model2에서는 느슨하게 정의되며 MVP에서는 형식적으로 정의됩니다.

MVP에서는 뷰가 인터페이스를 구현하며 프레젠터는 인터페이스의 멤버만 사용하여 뷰와 통신합니다. 따라서 프레젠터는 인터페이스의 메서드 및 getter를 사용하여 뷰의 입력 데이터를 읽고 인터페이스의 메서드 및/또는 setter를 사용하여 뷰의 새 값을 설정합니다. Model2에서는 강력한 형식의 컨테이너를 사용합니다.

MVP의 경우 프레젠테이션 논리는 UI 플랫폼으로부터 독립되므로 다른 플랫폼에서 같은 프레젠터를 재사용하기가 수월합니다. 또한 같은 프레젠터를 같은 응용 프로그램의 다른 뷰에 사용할 수 있으므로 SaaS(Software as a Service) 시나리오가 가능해집니다. 마지막으로 MVP의 경우 프레젠터에는 페이지 사이를 탐색하는 약간의 논리를 저장할 수 있습니다. 논리를 내부적으로 구현하거나 Windows WF(Workflow Foundation) 구성 요소를 사용하는 결정은 여러분에게 달려 있습니다.

페이지 컨트롤러 패턴

MVC, Model2 및 MVP는 ASP.NET 런타임 디자인의 외부에 있는 패턴입니다. ASP.NET의 Web Forms 프로그래밍 모델은 페이지 컨트롤러 패턴이라는 다른 디자인 패턴에 기반을 둡니다. 페이지 컨트롤러 패턴은 특정 웹 페이지 대상의 모든 HTTP 요청을 처리하는 중앙 개체(여러분의 코드 숨김 클래스에서 파생되는 동적으로 생성된 클래스)의 생성을 제어합니다(그림 7 참조).

그림 7 페이지 컨트롤러 구조

이 패턴을 사용자 지정하면 탐색 논리를 포함하여 페이지 간에 논리 재사용 측면에서 약간의 혜택을 볼 수 있습니다. 패턴을 사용자 지정하려면 간단하게 페이지 클래스의 계층을 만들고 계층 위쪽의 클래스에 탐색 및 프레젠테이션 논리를 통합하여 해당 논리를 파생된 클래스에서 사용할 수 있게 만들면 됩니다. 사용자 지정된 페이지 컨트롤러는 완전히 새로운 패턴으로 전환하지 않고도 프레젠테이션과 탐색 논리 재사용을 향상시킬 수 있는 좋은 방안이 될 수 있습니다.

MVP를 적용한다는 것은 기본적으로 페이지의 코드 숨김 클래스를 디자인한다는 것입니다. 즉, 페이지 클래스에서 인터페이스를 구현하고 별도의 구성 요소인 프레젠터를 사용하여 사용자 동작을 처리하게 됩니다. 요청은 일반적인 방법으로 코드 숨김 클래스에 라우팅되므로 런타임 환경은 변경되지 않습니다.

ASP.NET MVC Framework 프로젝트를 만든다는 것은 프런트 컨트롤러인 URL 라우팅 모듈을 사용하기 위해 컨트롤러에 대한 작업으로 요청을 확인하여 런타임 환경을 변경한다는 것을 의미합니다. 두 가지 선택 사항은 모두 응용 프로그램 개발에 영향을 미칩니다.

고려할 첫 번째 문제는 viewstate와 서버 컨트롤이 필요한지 여부입니다. 이러한 기술을 사용하지 않는 것이 나은 경우가 있습니다. 예를 들어 서버 컨트롤이 없으면 CSS를 사용하여 스타일을 적용하기가 훨씬 쉽습니다. 현재 AJAX는 ASP.NET MVC Framework 솔루션에서보다는 서버 컨트롤과 함께 사용하기가 수월합니다. 데이터를 많이 입력해야 하거나 복잡한 테이블 기반 뷰가 있는 응용 프로그램은 풍부한 서버 컨트롤 없이는 개발하기 어렵습니다. 따라서 궁극적으로 장단점이 있습니다. 핵심적인 질문은 서버 컨트롤과 viewstate의 필요 여부이며 여기에 명확한 대답은 없습니다.

Web Forms를 유지하면서 약간의 SoC를 원한다면 MVP가 적합합니다. MVP는 비교적 간단한 응용 프로그램에서 구현하기에는 비용이 다소 높은 중요한 UI 패턴입니다. 반면에 MVP는 여러 플랫폼에 걸쳐, 그리고 SaaS 시나리오에 프레젠테이션 논리를 최대한 많이 재사용하려는 엔터프라이즈 수준의 응용 프로그램에서 진가를 발휘합니다.

Dino에게 질문이나 의견이 있으면 cutting@microsoft.com으로 보내시기 바랍니다.

Dino Esposito는 IDesign의 설계자이며 Microsoft .NET: Architecting Applications for the Enterprise(Microsoft Press, 2008)의 공동 저자이기도 합니다. 이탈리아에 거주하고 있는 Dino는 전 세계의 IT 업계 관련 행사에서 많은 활동을 펼치고 있습니다. 문의 사항이 있으면 블로그weblogs.asp.net/despos를 방문하시기 바랍니다.

http://msdn.microsoft.com/ko-kr/magazine/dd365186.aspx