s you saw in the first article in this series
, ASP.NET automatically implements the Model-View-Presenter (MVP) pattern when you use the built-in "code-behind" approach. However other patterns, usually referred to as "controller patterns," are also suitable for use in ASP.NET. These patterns extend the capability for displaying a single view by allowing applications to choose which view to display at runtime depending (usually) on user interaction.
The Use Case Controller Pattern
The Use Case Controller pattern coordinates and sequences interaction between the system and its users to carry out a specific process. The "Wizard" interface style is an example; users step through a sequence of screens in a defined order. They may be able to go backwards as well as forwards, or jump to a specific step, but the overall approach suggests a defined "forward movement" through the process (see Figure 1
|Figure 1. The Use Case Controller Pattern: The diagram shows flow control in a typical Wizard-style interaction.|
In this pattern, a single Controller interacts with the Model (the data) and displays the appropriate view, depending on the user's interaction or the application's requirements. It is possible to incorporate multiple Controllers in a hierarchy for complex processes, and use configuration files or other persisted data to define the steps, which lets you alter control flow without recompiling and redeploying the application for easy maintenance and extension or alteration of the overall process. However, the underlying principles are as shown in Figure 1
The Page Controller and Front Controller Patterns
|Figure 2. The Page Controller and Front Controller Patterns: These patterns are well-suited to ASP.NET, because they support partial or alternate views.|
Two other design patterns related to Use Case Controller are the Page Controller and Front Controller patterns. These implement and extend the principles of the Use Case Controller pattern in a way that specifically suits ASP.NET. These patterns allow an application to either select the content to display in a page using different partial Views, such as varying page content composition with common headers and footers, or select which View (page) to display, such as pages that present different content depending on the browser or user credentials (see Figure 2
The Page Controller pattern uses a single Presenter (part of the MVP pattern implemented by the ASP.NET code-behind technology), which interacts with the Model (the data for the page). When it receives a request, the Page Controller can determine which partial View to display within the page, and then interact with that View following the MVP pattern.
In the Front Controller pattern, a separate controller examines each request and determines which page to display. Each page is a complete MVP implementation with its own View, and each Presenter interacts with the View and the Model (the data).
The Plug-in, Module, and Intercepting Filter Patterns
A series of related design patterns define how applications can use additional components or modules to extend their capabilities or perform specific functions. Typically, they allow the features or behavior of an application to change when it loads separate components that implement extra functionality
The Plug-in pattern usually relates to general-purpose software components. For examples, consider the way that Web browsers use ActiveX controls, Java applets, and the Macromedia plug-in to provide extra functionality or display Flash animations.
The Module pattern usually relates to the capability of an application to load and use custom assemblies (modules) that extend its functionality. An example is the Composite UI Application Block (CAB), which contains a feature that allows an application to load a complete interface component (such as a window with its associated Controller or Presenter and data), and integrate it seamlessly into a composite Windows Forms interface.
The Intercepting Filter pattern has a slightly different implementation. It usually consists of a component that resides within an application pipeline, such as the HTTP pipeline that ASP.NET uses to process each request. The framework calls a method within the HTTP module at a specific point during pipeline processing, allowing the module to change the behavior of the application.