Programming Microsoft ASP.NET 4 - Dino Esposito [320]
Web Forms and MVVM
MVVM is not a pattern I recommend for Web Forms. More precisely, the inherent plusses of MVVM don’t show up in Web Forms (or ASP.NET MVC) with the same effectiveness as they do in WPF or Silverlight. Still, MVVM can give you some benefits, such as layering, SoC, and testability. However, it won’t be anything more than what you would get with MVP.
Why is MVVM particularly effective in WPF or Silverlight?
The answer is shown in Figure 15-4. Used in a platform that provides superb support for (two-way) data binding, the MVVM shines and really gives you the aforementioned benefits with a fraction of the effort it would take to do the same in MVP. Used in Web Forms, where you have only one-time binding, it loses most of its appeal.
Figure 15-5 shows the graph of a XAML-based view designed in accordance with MVVM.
Figure 15-5. Schema of the MVVM pattern in a XAML-based view.
The XAML file can be a WPF, Silverlight, or even Windows Phone 7 view. It is made of markup elements bound to properties of the view-model object. The view-model object can be attached to the view in a number of equally effective ways, including programmatic access to the DataContext property of the view and a custom tag in the markup that references an external object. The view-model class exposes methods to retrieve and update data through the middle tier.
View events (for example, a user’s clicking) are bound to commands, and commands are ultimately mapped to methods on the view-model object. This can be done in a number of ways. You can, for example, use the code-behind class of the XAML view and just invoke methods on the view-model object, or perhaps you can use the XAML commanding interface to forward user events to command objects that, in turn, invoke the view-model and then the middle tier. Architecturally speaking, I don’t see relevant differences. It mostly depends on attitude and tooling. For example, if you use Microsoft Blend to create the XAML view, you’ll likely end up with codeless code-behind classes. If you stick to Visual Studio as your IDE, you will probably write classic event handlers in the code-behind class.
Implementing Model View Presenter
As it turns out, MVP is probably the most beneficial way of adding layering and testability to Web Forms applications. Let’s see how to implement the MVP pattern in a sample application.
Abstracting the View
In an MVP scenario, the first step to complete is defining the contract for each required view. Each page in the ASP.NET application will have its own interface to talk to the rest of the presentation layer. The interface identifies the data model that the page requires and supports. Two logically equivalent views will subsequently have the same interface. A view that extends an existing view will probably have its interface inherited from an existing one.
Note
What I’ll be saying for a global view such as a page applies verbatim to subviews such as user controls or, perhaps, frames.
From Use-Cases to the View
You always start development efforts from a use-case or perhaps a user story. In any case, you have a more or less defined idea of what the client expects your module to do and look like. You typically use wireframes to sketch out the final user interface of a given part of the application—commonly an individual view. After an agreement has been reached as to the information to show and templates to use (whether they are lists, tabs, collapsible panels, or data formats), you have just abstracted the view to a model. Figure 15-6 shows a possible mockup created with one of the most popular tools in this area—Balsamiq Mockups (see http://www.balsamiq.com).
Figure 15-6. A mockup showing a view for some default.aspx page.
With this idea in mind, getting an interface (or a base class)