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?

It should be a simple system for a large government organisation. Book a customer an appointment in one of many satellite offices at a particular time on a particular day. Why would someone create an Excel spreadsheet on a shared drive to solve this problem? What are the invisible costs of approaching IT systems in this way?

A little background first. I recently fell into the social safety net for various reasons. As a result, I’ve seen some of the effects of the new austerity measures on the provision of welfare in England.

First of all, the IT infrastructure hasn’t been refreshed in a number of years. That’s OK because these machines shouldn’t need to run lots of memory- or processor-hungry applications. The advisers shouldn’t be working on more than accessing the back end databases and writing letters. Any systems that the Jobcentres are using should take account of the fact there are a lot of advisers and a lot of old client hardware out there.

The systems in current usage don’t take that basic cost constraint into account. I was dealing with a woman who apologised repeatedly for having to open and close programs because having too many open applications at the same time caused her desktop to freeze. All you could see in her taskbar were collapsed icons for the many different applications that she had to keep open to do her job. As the interview progressed, she was constantly opening and closing programs to show me new information or to make changes.

One program in particular caught my attention. This was an old style mainframe application being shown through a terminal emulator. Every single task that was being done required the memorisation of a different alphanumeric code to get to the right screen. For a start, there is a time cost incurred. Every 10 second switch between screens, expanded to 30 seconds because every screen switch unexpectedly required a password to be entered, is time that is not spent on helping the customer. Secondly, how much time and money is spent training people to use systems like this? How much money is spent on hiring administrators to maintain such old (and untaught) technology?

What really made me laugh was finding out that one of the major cost-cutting measures was not giving out little plastic wallets to each customer. These wallets are perfectly sized for the paper documentation that they use as part of the review process and make it harder to accidentally lose one of those pieces of paper.

The example from the opening paragraph shows how crazy this whole thing is. During the initial interview, the adviser schedules you into one of the offices in the local catchment area. To do this, she opens an Excel spreadsheet from one of the many spreadsheet links on her desktop, enters your National Insurance number (Social Security number to anybody not familiar with English government), finds the right sheet, filters the data down to open slots, overtypes “BOOKED” into one field next to the slot you choose and then presses a button. Each day, somebody at each office builds a schedule for the day, prints that out, makes sure that each desk is labelled with a box number (printed from a word document, cut to A5 size and stuck to the cubicle wall with sellotape) and distributes it to each of the large number of advisers per office.

At first look, the big cost is the time spent entering the data. But there is plenty of waste elsewhere in the system too, from the over-use of paper to the time spent manually managing the schedules. This system is probably stable by now, but there still needs to be someone available in case of emergency.

What I propose is a module that is part of an over-arching system. This module would already know the national insurance number of the interviewee and their address so it can display the open slots for the appropriate office and the appropriate day for that person. Then, the adviser simply needs to select the time slot chosen by the interviewee and click next. In the offices, schedules can be checked by looking at the data on a screen at the front desk instead of books full of paper for each day.

For those that are more persuaded by the financial numbers than this summary of a systems analysis – consider these approximate statistics. In December 2010 there were 1.456 million claimants of JSA. Every one of these should have visited a job centre office twice in that time. If one person in a thousand makes a change to their appointment time and one in a hundred of those changes results in a mistake that is still 145 mistakes a fortnight across the country. Assume that a mistake costs 20 man-minutes at the minimum wage rate of £5.93 and that means that £22 thousand pounds a year are spent dealing with these avoidable situations.

Of course, that’s just mistakes. Look at the cost of printed schedules. Assume an office prints an average 10 pages each day for their schedules. If a page costs 10 pence, then across the fortnight, each office would spend £20 on printing those schedules. Across all 141,ooo individual offices that means £1.41 million in printing costs! Of course, electricity isn’t free, so you won’t save all £1.41 million by switching to an electronic monitor based system. In comparison, assuming a reasonable kWh cost of 9.7p, one extra monitor for all 141 thousand job centre offices will cost approximately 0.1 million pounds. That is a factor of ten reduction in costs, just from one change!

All this is back of the envelope math. How much do you think you would spend to figure out if it is worth it? How much would you spend if these savings turn out to be possible? How much more do you think could be saved if an end-to-end rebuild was done?

There are many ways to reduce costs but most require investment. This is possible, even in an environment that seems hostile to spending more money. All it takes is people willing to actually understand systems and change them for the better.