Programming Microsoft ASP.NET 4 - Dino Esposito [318]
The controller has no dependencies on the view; the controller only knows the model and how to reach the middle tier.
Web Forms and the MVC Pattern
Heavily based on view state, code-behind, and server controls, the Web Forms programming model follows its own pattern—the Page Controller pattern. The core idea is that any request is mapped to a page and an internal component controls the request, including input processing, action, and output generation. If you stick to Web Forms, you can’t eliminate the Page Controller pattern.
If you want more SoC, you can build layers for models and controllers on a per-view basis. This means that each Web Forms page should have its own model class and its own controller class. The model will be updated with any posted data and any significant data that is read out of the view state. In the postback, the code-behind event handler will simply invoke a controller method. Finally, the controller will update the model, and these changes should walk their way to the view.
The weak point of MVC is the communication between view and model. The original MVC paper suggests you set up event-based communication between the two. Years of experience suggest a different model should be used. Enter the MVP pattern.
The MVP Pattern
MVP is a derivative of MVC aimed at providing a cleaner separation between the view, the model, and the controller. The most relevant change from MVC is that view and model are physically separated and have no intimate knowledge of each other. The controller (renamed as presenter) is a mediator between the user and the application. Solicited by the view, it performs any work associated with the request and passes data back to the view. In MVP, the controller class is essentially responsible for presenting data to the view, which explains the new name of “presenter.”
Generalities of the MVP Pattern
As mentioned, in MVP the view and the model are neatly separated, and the view exposes a contract through which the presenter can read input values and provide results of the action. Summarizing the situation further, we can say that MVP is a refinement of MVC based on three facts:
The view doesn’t know the model.
The presenter ignores any UI technology behind the view.
Abstracted to an interface, the view is easy to mock up, which makes testing the controller far easier.
Figure 15-2 provides an overall view of the MVP pattern.
Figure 15-2. The MVP pattern.
The presenter is at the center of the universe and incorporates the presentation logic behind the view. The presenter in MVP is logically bound to the view, which is another reason for emphasizing the presentation role of the component. Figure 15-3 attempts to compare MVC and MVP graphically.
Figure 15-3. Comparing MVC and MVP.
Note
In addition to the change of name (controller vs. presenter), there’s a more subtle but relevant point. In MVC, the controller is a centralized class that handles multiple calls from multiple views. In MVP, the presenter is bound to a single view or to a hierarchy of views with the same characteristics. In MVP, the presenter is a controller for a specific segment of the presentation logic. Hence, the name “presenter.”
Role of the Model
The best possible definition of the model doesn’t change in MVP. The model is the representation of the data being worked on in the view. As shown in Figure 15-2, the view exposes a contracted interface, which represents the core functionality of the view to the presenter’s eyes. In other words, the presenter should be able to work with any object that implements that contracted interface.
In theory, it could be an ASP.NET page as well as a Windows Forms window. The model in MVP, therefore, is the interface that the view object implements. Being an interface, it can include properties, but it can also include methods and events. In a Web Forms scenario, events are not required, and most of the time it will contain just properties.
Role of the View
The view is the