Pattern Web Solutions

Almost anywhere you look these days you can see these acronyms popping up. What do they mean to the .NET developer and are they more than somebody throwing a letters at the screen?

All three of these acronyms describe (subtly different) approaches to application development based on the separation of business and user interface logic. In all three, the MV stands for Model-View which is the portion of the approach relating to storing and presenting data. The last letters describe how that data is manipulated within the application. -C is -Controller, -P is Presenter -VM is ViewModel. Hold on, these words will all make more sense soon.

Models are small simple data objects that are responsible for containing valid data and nothing more. A UserAccount is an example of a Model, it can have a FirstName, LastName, EMailAddress, Password and so on. Often the Model will have validation logic, so that a Password must meet defined security rules like being at least 8-10 characters long and include at least one letter and one number.

Views transform data from their internal system representation as a Model to a form that the external user can understand. There can be many Views for a particular Model. For example, the same UserAccount Model can be presented to another user as a profile page or to the active user as an account editing page.

MVC

Over the last 3 years, MVC has been popularized in the .NET community by the ASP.NET MVC project. Now at version 3, this project promises to deliver a framework for web development that encourages fine-grained testability and managed complexity. Their overview goes over these goals in more detail.

MVC has a much longer history though. Much of the early work of the Microsoft teams builds on the work of Ruby on Rails and there are still many similarities in the core philosophy.

The Controller objects in MVC are groups of related behavior. It can provide functionality to select and manipulate Models and encapsulates all the relevant business logic. The Controller doesn’t need to know how to validate the data in a Model or to interface with the user.

For example, a User Controller can provide a Search action and an Update action. When a request from the interface to search for a User with a particular name comes in, the Controller looks for Model objects that have that name and provides it to a View which translates the collection of objects into a list the user can see and interact with. When they change something and request that the changes be saved, the Controller runs through all the required logic such as asking the updated Model if it is currently valid and saving it to the persistent store.

This approach works very well when you care about changing the way actions are performed more than how data is presented. It is very easy to add another action to one controller that can be used from anywhere, like TransferToShipping, without having to add a dependency to every view that could possibly use it.

The modern MVC frameworks are most at home on the web because a URL maps easily to a View-independant controller and action. The action-bias is more difficult to present in the current desktop paradigms.

MVP

MVP in general is a derivative of MVC in general. It focuses on the View and how to support it in a testable and manageable way. WebformsMVP is a reaction to ASP.NET MVC that intends to bring the same tools to the View-first method of development.

The Presenter of MVP does much the same job as the Controller in MVC. The major difference is which object is the logical container. Controllers take input directly from the interface, instantiate the appropriate View with a Model and provide the View to the interface. The View in MVP handles all input and uses the Presenter to perform actions and format data to be displayed in the widgets on the View.

A View in this approach would be a UserView. It would include all necessary controls to find and display the data from a UserModel. The UserPresenter’s role is to update the UserView’s controls with formatted data from the UserModel and perform actions requested by the UserView. To make this less brittle, the UserPresenter is programmed against the IUserView interface. Specific UserView objects could be windows forms, web forms or something else. So long as they provide the relevant properties, all is well.

This approach works great when you want your visual presentation to be the first point of change and you worry most about what users will do from one visual starting point. This is because one Presenter is tied to one View interface.

MVP works equally in Windows Forms and Web Forms because all a Presenter needs is a View that conforms to a particular interface.

MVVM

MVVM is a pattern with a very specific job. That job is to separate the code that sets visual properties from Model data when you use WPF and Silverlight. In many ways, it acts like the Presenter in MVP, but instead of coding to an interface it provides properties that can be subscribed to. Jeremiah Morril has written a code-based introduction to MVVM that explains the method in much more detail.

A UserViewModel will act much like the Presenter above but instead of setting the properties on an IUserView object, it will set properties on itself. The SilverlightUserView will pick those up and update the interface by itself.

MVVM works when you are using Silverlight or WPF. The ViewModel conversions will be designed for Views written on those frameworks to consume. In other ways, it works in the same way as MVP. However, it has been noted by Davy Brion that adding conversion logic to a Presenter may violate the Single Responsibility Principle.

Summary

The approach you choose to separate business and UI logic is driven by one distinct choice. Do you care about presenting actions or data to the user. If you want to give someone actions and use the domain model to support that, go with MVC. If you want to to start with data and let the user take actions that relate to what they can see, go for MVP (or MVVM if you are on Silverlight/WPF).

What approach do you use and what for?

Tags: c#

This entry was posted on Friday, February 25th, 2011 at 23:22 and is filed under Essays. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.