Contents

• Model-View-Controller and some variants
• Basic MVC
• Extending basic MVC
• Active Models
• Multiple Controllers
• Pros and Cons of basic MVC
• Page Controller
• Pros and Cons of Page Controller
• Front Controller
• Pros and Cons of Front Controller
• Page Controller Implementation
• Front Controller Implementation
• Notes on the implementations

The prime sources of information for this article are: Martin Fowler, Patterns of Enterprise Application Architecture, MSDN and subsequent pages and Object Arts, the creators of Dolphin Smalltalk.

• Presentation and Model are fundamentally different and are developed with different concerns and different techniques.
• Separating the Model from its presentation allows multiple representations to be developed.
• Automated tests for a separate model are easy; automated tests for a UI are complex to set up and fragile. Separating the model from its presentation allows it to be tested relatively easily.
• The Views can be changed without impacting the underlying Model or even the Controller.
• Multiple views of the Model are easy: having a Web, a WinForm, a WAP Phone, and a character-based presentation have no impact on the model whatsoever.

• MVC introduces extra levels of indirection and thus complexity
• Active Models introduce yet more complexity and can also, in extreme cases, flood a view with update events.
• Basic MVC concentrates on the separation of the Model and the View; the controller is less important.
• Controllers are likely to have a lot of duplicate code for tasks such as authentication, parsing a query string, reading and writing Session information, etc. This is inefficient.

• Decode the URL requested and extract any form data
• Access the Model to retrieve or process the data requested. All HTTP data required should be extracted and passed to the Model so that the Model objects don't have any dependencies of their being an HTTP Context.
• Determine which View is appropriate for the results and forward the Model information to it.

public class BaseController {
	protected void Page_Load(object sender, EventArgs e) {
		if (this.InvalidUrlForSomeReason) {
			transferToErrorPage(invalidUrlReasons);
		}
		DataSet ds = LoadData();
		if (HasNoData(ds)) {
			transferToErrorPage("No data matched request");
		}
		ApplyDomainLogic(ds);
		DataBind(ds);
	}
	protected virtual bool InvalidUrlForSomeReason() {
		// validate url
		// maybe set private string invalidUrlReason
	}
	protected abstract DataSet LoadData();
	protected virtual void ApplyDomainLogic(DataSet ds) {
		// do something with the data - add a calculated column etc
		// or just leave blank as here if no logic to apply
	}
}
			

• Because each dynamic web page is handled by a specific Page Controller the controllers have limited scope and are thus relatively simple.
• This pattern is built-in in ASP.NET and is thus easy to implement.
• Controller Base classes reduce duplication and promote re-use
• If Page Controller is not suitable for every page in the site it need not be used by every page in the site.

• In a site with complex dynamic navigation it is not always possible to abstract the navigation completely to a Base controller. The navigation thus becomes spread out over the site and difficult to maintain.
• The Page Controllers are dependant on the Http context and are thus difficult to test. If they contain too much logic this decreases the testability of the system. The parts which do not depend on Http (or from which that dependence can be removed such as the ApplyDomainLogic method above) can be removed to separate classes but although these can then be tested separately it introduces another layer of indirection and thus complexity.

• If common logic is duplicated in different views of the system; this needs to be centralised to reduce duplication and increase maintainability
• If data retrieval is best handled in a central location
• BasePageControllers can bloat with code not common to all implementers.
• If BasePageController is refactored in different base controllers to remove unused abilities from inheritors, you can end up with a large deep inheritance hierarchy. This can lead to brittle designs and implementations and is hard to understand.
• Page Controller breaks down when you need to control or coordinate a process across multiple pages.

• Statically: using conditional logic on the URL
• Dynamically: putting the name of the Command in the URL
• Dynamically: using a config file keyed on all or part of the URL to map to a command class name

• The single Handler is in the perfect place to apply system-wide policies with no duplication
• Since each Command is instantiated as a new object, Thread Safety is not an issue. (Note that it is an issue with the Model.)
• Using Dynamic despatching is very flexible

• The Handler can become a performance bottle-neck. If it has to make a database query or parse say a large complex XML document to decide which command to despatch performance could be affected.
• Front Controller is more complex than Page Controller. MSDN has an example implementation of in which it says: "Because Page Controller is built into ASP.NET, the additional effort required to implement Front Controller rather than Page Controller is very large. In fact, you must build the whole framework for Front Controller. You should do so only if your application warrants that amount of complexity. Otherwise, review Page Controller to determine whether it is sufficient."
• The is no way inherent in the pattern to send the data collected by the ConcreteCommand into the View. One could always stuff a DataSet into the session object, but this re-introduces a dependency on the HTTP context into the Command. Other schemes are imaginable, though.

	protected Label eMail;
	protected Label siteName;

	virtual protected void PageLoadEvent(object sender, 
							System.EventArgs e) {
	}
   
	protected void Page_Load(object sender, System.EventArgs e) {
		if(!IsPostBack) {
			string name = Context.User.Identity.Name;

			eMail.Text = DatabaseGateway.RetrieveAddress(name);
			siteName.Text = "PageControlled-site";
				PageLoadEvent(sender, e);
		}
	}
		

		<!-- #include virtual="BasePage.inc" -->
		

<table width="100%" cellspacing="0" cellpadding="0" ID="Table1">
	<tr>
		<td align="right" bgcolor="#9c0001" cellspacing="0" 
					cellpadding="0" width="100%" height="20">
			<font size="2" color="#ffffff">Welcome:
				<asp:Label id="eMail" runat="server">username</asp:Label>
			</font>
		</td>
	</tr>
	<tr>
		<td align="right" width="100%" bgcolor="#d3c9c7" height="70">
			<font size="6" color="#ffffff">
				<asp:Label id="siteName" 
						Runat="server">Micro-site Banner</asp:Label>
			</font>
		</td>
	</tr>
</table>
		

namespace ghytred.PageController {

	public class Page1 : BasePage {
		protected System.Web.UI.WebControls.Label pageNumber;
	

		#region Web Form Designer generated code
		#endregion

		protected override void PageLoadEvent(object sender, 
						System.EventArgs e) {
			pageNumber.Text = "1";
		}
	}
}

	protected void Page_Load(object sender, System.EventArgs e) {
		if(!IsPostBack) {
			string site = Request["site"];
			if (site != null && site == "macro") {
				LoadMacroHeader();
			} else {
				LoadMicroHeader();
			}
		PageLoadEvent(sender, e);
		}
	}
		

using System;
using System.Web;

namespace ghytred.FrontController {
	public class Handler : IHttpHandler {
		public Handler() {
		}
		public void ProcessRequest(HttpContext context) {
			ICommand command = 
			CommandFactory.Command(context.Request.Params);

			command.Execute(context);
		}
		public bool IsReusable {
			get { return true; }
		}
	}
}
		

using System;
using System.Web;
using System.Collections.Specialized;

namespace ghytred.FrontController {

	public interface ICommand {
		void Execute(HttpContext context);
	}

	public class CommandFactory {
		private CommandFactory() {
		}
		public static ICommand Command(NameValueCollection parameters) {
			string siteName = parameters["site"];
			switch (siteName) {
			case "Macro":
				return new MacroCommand();
			case "Micro":
				return new MicroCommand();
			default:
				return new UnknownCommand();
			}
		}
	}
}
		

	<httpHandlers>
		<add verb="*" path="Page*.aspx" 
			type="ghytred.FrontController.FCHandler,FrontController" />
	</httpHandlers>
		

public abstract class RedirectingCommand : ICommand {
	
	protected abstract void OnExecute(HttpContext context);
	
	public void Execute(HttpContext context) {
		OnExecute(context);
		string url = String.Format("{0}?{1}",
					UrlMap.Instance[context.Request.Url.AbsolutePath],
					context.Request.Url.Query);
		context.Server.Transfer(url);
	}										  
}
		

public class MacroCommand : RedirectingCommand {
	protected override void OnExecute(HttpContext context) {
		string name = context.User.Identity.Name;
		context.Items["address"] = 
				MacroUsers.retrieveAddress(name);
		context.Items["site"] = "Macro-site";
	}
}
public class MicroCommand : RedirectingCommand {
	protected override void OnExecute(HttpContext context) {
		string name = context.User.Identity.Name;
		context.Items["address"] = 
				MicroUsers.retrieveAddress(name);
		context.Items["site"] = "Micro-site";
	}
}
public class UnknownCommand : RedirectingCommand {
	protected override void OnExecute(HttpContext context) {
		string name = context.User.Identity.Name;
		context.Items["address"] = 
"user " + name + " is unknown";
		context.Items["site"] = "Unknown";
	}
}
		

public class UrlMap {
	private UrlMap() {
	}
	// Show off Singleton implementation
	private static UrlMap instance;
	private static object thingToLock = new object();
	public static UrlMap Instance {
		get {
			if (instance == null) {
				lock(thingToLock) {
					if (instance == null) {
						instance = new UrlMap();
					}
				}
			}
			return instance;
		}
	}
	public string this[string requestedPage] {
		get {
			// prefix page name with "Actual"
			string[] parts = requestedPage.Split('/');
			int i = parts.Length - 1;
			if (i < 0) {
				i = 0;
			}
			parts[i] = "Actual" + parts[i];
			string actualPage = String.Join("/", parts);
			return actualPage;
		}
	}
}
		

	protected void Page_Load(object sender, System.EventArgs e) {
		if(!IsPostBack) {
			eMail.Text = (string)Context.Items["address"];
			siteName.Text = (string)Context.Items["site"];
			PageLoadEvent(sender, e);
		}
	}
		

Cruel and unusual punishment. This implementation is a lot more complicated than Page Controller. This implementation does provide more options, but at the cost of complexity and a lot of classes. You must weigh whether or not it is worth it. After you have taken the leap and built the framework, it is easy to add new commands and views. However, due to the implementation of Page Controller in ASP.NET, you would not expect to see as many implementations of Front Controller as you would in other platforms.