The only other code the Presenter requires is button-click handlers. The event handlers for the “Back” and “Next” buttons change the value of the viewName local variable, and then call the LoadAndDisplayView method to display the current view. The event handler for the “Cancel” button just redirects the request back to the default page of the example application:

   protected void btn_Back_Click(object sender, EventArgs e)   {      switch (viewName)      {         case "CustomerDetails":             viewName = "CustomerList";            break;         case "CityList":             viewName = "CustomerDetails";            break;      }      LoadAndDisplayView();   }      protected void btn_Next_Click(object sender, EventArgs e)   {      switch (viewName)      {         case "CustomerList":            viewName = "CustomerDetails";            break;         case "CustomerDetails":            viewName = "CityList";            break;      }      LoadAndDisplayView();   }      protected void btn_Cancel_Click(object sender, EventArgs e)   {      Response.Redirect("Default.aspx");   }

To see the results, look back at Figure 4, 5, and 6. These show the three views that the Use Case Controller example displays as you click the “Back” and “Next” buttons.

Implementing the Page Controller Pattern
ASP.NET automatically provides a Presenter implementation for the Model-View-Presenter pattern through a code-behind file for each ASP.NET page. However, you can extend the implementation by adding your own Page Controller in the form of a base class that the code-behind files inherit.

By default, the code-behind class for an ASP.NET page inherits from the Page class in the System.Web.UI namespace. If you create a suitable base class that inherits from Page, you can use this as the base for your own concrete implementations of the code-behind class. This is useful if some or all of your pages require common functionality.

The base class can also perform some of the tasks of a Page Controller by handling the Page_Init or Page_Load events. For example, code in the Page_Load event can select a View to display at runtime for a page, allowing a single page to change its content based on some external condition such as a value in the query string.

The example application uses a base class named PageControllerBase (in the App_code folder), which inherits from System.Web.UI.Page and exposes three values that the concrete classes that inherit from it can access. These values are a reference to the partial View (a user control) to load and display, the name of the View, and a string value to display when no View is specified:

   // base class for TransferPage2 and TransferPage3   // implements common tasks and can call method(s)   // in the concrete page class implementations    public class PageControllerBase : Page   {      // values that will be available in page class      protected UserControl displayView = null;      protected String displayViewName = String.Empty;      protected String noViewSelectedText = "No View Selected";      ...

The PageControllerBase class handles the Page_Load event to get the name of the View to display from the query string, and then attempts to create an instance of the appropriate user control for the concrete page code to access. At the end of the Page_Load event handler, the code calls a method named PageLoadEvent, passing in the values of the sender and EventArgs originally received as parameters:

   protected void Page_Load(Object sender, System.EventArgs e)   {      // get name of view (UserControl) to show in the page       displayViewName = Context.Request.QueryString["view"];      if (displayViewName != null && displayViewName !=          String.Empty)      {         try         {            // load view from ASCX file            displayView = (UserControl)               Page.LoadControl(displayViewName + ".ascx");         }         catch { }      }      // call concrete page class method      PageLoadEvent(sender, e);   }

Every page that inherits from this base class must implement the PageLoadEvent method. To ensure that this is the case, the PageControllerBase class declares a virtual method that each concrete page implementation must override:

   // define method that concrete page classes must implement   // and will be called by this base class after Page_Load   virtual protected void PageLoadEvent(Object sender, System.EventArgs e)   {       // overridden in concrete page implementation   }

The example application contains two pages, named TransferPage2.aspx and TransferPage3.aspx that inherit from the PageControllerBase class. The code in the overridden PageLoadEvent methods is the same in both pages?it is only the View (the ASPX UI) that differs. However, they could be completely different if required, although all inheriting page should make some use of the common functionality of the PageControllerBase class (or there is no point in inheriting from it!). Here’s the PageLoadEvent code used in both pages:

   public partial class TransferPage2 : PageControllerBase   {      // override virtual method in PageControllerBase class      protected override void PageLoadEvent(Object sender,          System.EventArgs e)      {         // use values that were set in base class Page_Load event         if (displayView != null)         {            pageTitleElement.Text = "Displaying view '" +                displayViewName + "'";            pageHeadingElement.InnerHtml = "Displaying view '" +                displayViewName + "'";            PlaceHolder1.Controls.Add(displayView);         }         else         {            pageHeadingElement.InnerHtml = noViewSelectedText;         }            // display actual URL of currently executing page
?
Figure 7. The CityList View: The figure shows two differing views of the same page.
         lblActualPath.Text = Request.CurrentExecutionFilePath;         String qs = Request.QueryString.ToString();         if (qs != null && qs != String.Empty)         {            lblActualPath.Text += '?' + qs;         }      }   }

The preceding code displays the name of the current View in the page title and heading, and adds the user control instance created by the PageControllerBase class to the Controls collection of an ASP.NET Placeholder control declared in the ASPX file:

The final section of the PageLoadEvent method shown above displays the actual page URL so that you can see the effects of the Front Controller implementation (described in the next article in this series). Figure 7 shows the two pages described in this section displaying the “CityList” View.

Implementing the Front Controller Pattern
The most common approach for implementing the Front Controller pattern in ASP.NET is through an HTTP Module that handles one of the ASP.NET HTTP pipeline events, and executes a Server.Transfer action to load the appropriate target page. This is the technique implemented in the example application. A dropdown list at the bottom of the Default.aspx page displays a list of possible targets, from which you can select (see Figure 8).

	?
Figure 8. Sample Application Page Targets: The figure shows the list of targets for the Front Controller example displayed in the default page.

You may recall from the discussion of the Singleton pattern in the previous article in this series that the example application uses a Singleton class named TransferUrlList.cs to expose the contents of an XML file that contains the target “short names” (as displayed in the dropdown list in Figure 8) and the actual URL to load:

To demonstrate the Front Controller pattern, the application contains a class named FrontController.cs (in the App_Code folder) that implements an HTTP Module. The class declaration indicates that it implements the IHttpModule interface, which means that it must declare the public methods Init and Dispose.

In the Init method, the class subscribes to the PreRequestHandlerExecute event by registering an event handler named MyPreRequestHandler. As the class does not use any unmanaged resources, the Dispose method requires no action?so it declares only an empty method:

   public class FrontController : IHttpModule   {      public void Init(HttpApplication context)      {         // register a handler for the event you want to handle         context.PreRequestHandlerExecute += MyPreRequestHandler;      }         public void Dispose()      {         // no clean-up required      }      ...

The ASP.NET HTTP pipeline raises the PreRequestHandlerExecute event just before it executes the request. The code in the event handler in the FrontController module can therefore make a decision about which page to load based on some external condition. This may be something like the browser language, country, browser type, a value in the user’s ASP.NET Profile, or some other value from the environment.

The example module takes simpler approach to make it easier to specify the target you want when experimenting with the application. It examines the query string for a value that corresponds to one in the list of transfer URLs exposed from the XML file, and redirects to the appropriate page. The GetTransferUrl method of the TransferUrlList class returns the translated URL if found in the list, or the original URL if it is not in the list. The code then executes the Server.Transfer method to that URL:

   private void MyPreRequestHandler(Object sender, EventArgs e)   {      // use features of the request (user, browser,       // IP address, etc.) to decide how to handle the request,       // and which page to show.      // this example looks for specific items in the query       // string that indicate the required target (such as       // "CustomerList") using a dictionary of values loaded from       // an XML disk file         // get Singleton list of transfer URLs       TransferUrlList urlList = TransferUrlList.GetInstance();      // get the current request query string      String reqTarget = HttpContext.Current.         Request.QueryString["target"];      if (reqTarget!= null && reqTarget != String.Empty)      {         // see if target value matches a transfer URL         // by querying the list of transfer URLs         // method returns the original value if no match          String transferTo = urlList.GetTransferUrl(reqTarget);         try         {            // transfer to the specified URL            HttpContext.Current.Server.Transfer(transferTo, true);         }
?
Figure 9. Effect of Selecting "CustomerDetails": When you select the "CustomerDetails" item in the dropdown list, the application loads TransferPage2, which displays the CustomerDetails View as shown here.
         catch { }      }   }

When you select one of the “short name” values in the dropdown list in the default page of the application, you’ll see the effects of the Front Controller module. For example, Figure 9 shows the result of selecting the “CustomerDetails” option. The code in the Front Controller HTTP module translates this into the URL TransferPage2.aspx?view=CustomerDetails?as you can see in the Label control that displays the actual URL of the current page.

Notes on Using a Front Controller HTTP Module
You may be tempted to try using URLs for your Front Controller that include the “short names” as part of the path, rather than in the query string. This will work when you run your application within Visual Studio 2005 because all requests go to the built-in Visual Studio Web server. However, if you run your application under the IIS Web server you will get “Page Not Found” errors, because IIS passes only pages that actually exist to the ASP.NET runtime.

For example, if you use a URL such as http://localhost/CityList, and there is no folder in your Web site named CityList, IIS will return a “404 Not Found” error. It will not initiate the ASP.NET HTTP pipeline, and so your module will not execute. Even if the CityList folder does exist, IIS will return either a “403 – Forbidden” error, or (if Directory Browsing is enabled) a file listing.

Of course, you could create a folder for each “short name” and put an empty ASPX page in each of these folders so that the Front Controller module redirects to the appropriate page as required. This is better than using pages that contain redirection code (such as Response.Redirect or elements) in each folder, because the Front Controller will intercept each request and will not actually load the empty ASP.NET page.

An alternative is to map all requests to the ASP.NET runtime DLL, rather than just the standard ASP.NET file extensions such as aspx and ascx. However, this is probably not a practical solution because it will result in an excessive processing overhead in ASP.NET.

As you are probably beginning to realize, ASP.NET makes extensive use of design patterns internally, and you can capitalize on design patterns yourself to build logical and easy-to-maintain applications. I’ll cover some more advanced patterns in the final article in this series.