MVC architectural pattern in ASP.NET

The MVC pattern in general
When talking about presentation framework, it seems that the most popular architectural pattern used is the MVC (Model-View-Controller). The model stands for the application logic - e.g. this is where data structures are manipulated, database and business components are accessed. The View and Controller stands for the user interface of the framework. Conceptually the user interface may be considered as a combination of input and output components. In the MVC case the View and the Controller may be considered as these output and input components. It is very true in HTML/HTTP based environments. The Controller receives the user requests (serves as input) and the View outputs content to the user. This pattern enforces the actual representation (View) to be separated from the application logic (Model).
In the Java community MVC stands also for the original MVC implementation (by using JSP for the controller/view implementation and JavaBean for the Model implementation) which brakes a little bit the idea proposed by the MVC pattern. Later Sun proposed second implementation of the MVC pattern, called MVC2.

The MVC pattern from the ASP/NET tower
Going down from the abstract patterns and closer to the implementation details, we will see that ASP.NET uses an implementation of the MVC called Page Controller. (one may argue if the Page controller should be consider as an architectural pattern or implementation aproach, however it depends on the goals of the analysis). Unfortunately it is not quite useful aproach, when dealing with large complicated applications. I talk about the cases, when we have requirements for a complicated workflow management, aggregation of multiple and heterogeneous backend resources, end-user device specific content rendering, long application lifecycle and frequent business model changes.
In this case another MVC implementation approach is more appropriate. It is called Front Controller. ASP.NET does not propose this kind of MVC implementation, however it provides the tools to build such a framework.
A suitable aproach for implementing a Front Controller is to implement use IHttpHandler interface implementation for controller. The IHttpHandler interface implementations are "plugged-in" the ASP.NET request processing pipeline. They are very clear way to imlpement the Controller pattern.
Here comes an example of a Front Controller implementation
The proposed implementation is a good start playing with a front controller implementation. However it uses *.aspx files to represent a single view. This aproach may introduce quite heavy development effort if we have a large number of views to implement.
And beacause in this case, we will have longer and complicated development period it is more probable to inject more defects in the final solution. One way to mitigate this risk is to use alternative View implementation.
The .NET framework introduces the System.Xml namespace. It implements a large number of classes for Xml manipulation.
This is where we may search for an elegant solution. We'll need to acomplish the following steps:
1. Design custom Xml based declarative language to define our views - Xml schema. We call this Xml View Definition
2. Design and implement Xml View Definition Processor. It may be composed of 2 parts: Xml View Transformation (xslt) and code-based processor. In order to compose our view in ASP.NET format we will execute the following steps:
      2.1. *Convert the Xml View Definition file by using our Xml View Transformation and receive html content.
      2.2. Pass the html content to the Page.ParseControl method and add the list of the controls to the Page.Controls collection
      2.3 **Pass the Xml View Definition to the code-based processor in order to handle additional processing - for example Event Binding,Data Binding...,
* We may have a separate Xml View Transformation for every type of end-user device: IE,Netscape, PDA, smart Phone, e.g.
   and why not XAML
**A lot of work may be done by the Xml Transform Processor by using the XsltArgumentList.AddExtensionObject method to add
   references to .NET classes. These classes may be invoked by the transformation processor during the Xslt transformation        process. This way, we may avoid the need from a separate code-based processor.

Note that this only scratches the complexities of implementing such a framework. In order to have fully declarative views definition it will be beneficial to develop a declarative workflow definition also. This workflow definition should be processed by the Controller. However the benefit from using such a declarative aproach for a View definition may reduce the resources needed to maintain/update the solution in a rapid changing business environment. Of course these aproach has its limitation so pros and cons should be estimated against every particular project.

Following some common pros and cons:
Pros:
* The declarative views/workflow definition eliminates the need of a complex development knowledge for adding new views to the solution
* The Xml View definitions may give opportunity to support multiple end-user device types.
* Possibility for easier changes in the workflow and views in order to respond to business changes

Cons:
* Greater development impact during the general framework implementation. It may be not suitable for every project.
* The workflow/view maintainability comes with a performance cost. This may be compensated (a bit ) by utilizing a good caching scheme.
* Implementing a good post back handling is a challenge
* It may be chalenging to embed third party ASP.NET based Web Controls.