As previously stated I’ve been using Model View Presenter as a design pattern in some form or other for over a year now. My understanding of how to implement it and the way I’ve used it have changed over the past year, but the fundamentals have remained the same. Recently I have been preaching the gospel of MVP to my co-workers, in fact I’ve written into our coding standards as our current best approach for application development. Whilst my previous MVP entry was aimed at those that understand the principle and want to implement it I am aiming this at those that want to learn what it’s all about.
A word of note, I’ll not be touching on Model View Controller, MVC.NET and any of its REST like abilities, because although they may be related in some abstract design way, implementations of MVP and MVC are different.
There are many good reasons to use MVP, testability, separation of layers, common application structure across different development streams, all of which have been documented and are part of the rise of interest in MVP. For me one of the main advantages about MVP is the way it separates it’s layers, it helps create a clear and focused design and development process. Even without the testability I find this reason enough to use MVP as my pattern of choice.
Like most patterns MVP is best represented by a diagram:
Click image to enlarge
Also like most patterns, the diagram can seem relatively impenetrable when you are first starting out trying to understand it. Whilst you can ramp up the complexity of your implementation quite quickly a basic understanding is a must. You can see in my previous post about a VB.Net MVP template an example of Hello World developed with the MVP pattern.
It is simpler to think of MVP in terms of separation of layers to begin with than it is to think of it in terms of calls and communications between classes. The following diagram shows the layer separation at work within my implementations of MVP:
My version of the diagram
Click to enlarge
In effect it is a simple n-tier architecture. The View that implements the IView interface only cares about its properties and how it is displaying them. The Model only cares about its methods and how it is going to get the information requested of it. The Presenter only cares about your abstract logic and being the vessel for passing calls between the View and the Model. For database driven web applications the methods in the presenter can often just be the hooking up of a View property to a Model method to return the required data.
Once you have straightened out how the tiers work in MVP the next hurdle was what “knowledge” each of the parts have about each other. I’ve done this in a cascading manner, the View instantiates a Presenter, the Presenter is passed the View, when it is instantiated, and in turn instantiates the Model. The Model handles data access through helper classes and business objects. So the View only knows what Presenter it’s using, the Presenter only knows it has a View and a Model, the Model doesn’t know where its data is going to, but knows how to get it. In this way every part of the code is essentially hot swappable in a modular manner. We can completely rework the entire Model and never have to worry about changing anything in the View, and vice versa.
That’s the theory anyway.
My actual implemention, or: How I develop software.
Whilst the Pattern of MVP is relatively well defined actual implementations may vary. This is how I implement Model View Presenter.
My View interface will usually consist of a series of properties that I will have indirectly bound to controls. To establish my view I sit down with a pen and paper and work out my UI elements, text entry boxes, lists, comboboxes and whatever else might make up your particular interface. From there it is a case of working out what type of property they will be, if something will always be a number I’ll define it as an integer, otherwise it usually ends up as a string or a collection, I have recently been moving away from Datasets towards using collections.
During the design phase of my project I will sit down and work out what my program actually does. Most database back ended applications tend to have insert, update and delete, with a few other bits and pieces thrown in. For my Skimmp3 application I have a bit of paper that says “Get all the links on a website that are mp3s, download all mp3s from a website” and that is all. These inform me of what my model level should be doing. I can infer my methods from these lists of What does my program do?
For my own projects I will also define my business objects, what will be passing through my program? What will I have collections of? Sometimes the things that have fallen out of “What does my program do?” will work better at an object level, for example “Save Settings”, you may have a settings object that you put the Save() method in, it seems more sensible to put it with object than in the model.
At this point I’ll usually start bashing away at code. First defining my objects, then defining my model interface, I’ll implement the interface in the model class and then fill in skeleton functionality.
I then like to return to my View and implement an interface, whilst hooking up the form (windows or web) controls to the properties of the View.
This then leaves me to wire it all up with the presenter. In theory at this point it will all compile, but not actually do very much. By fleshing out the Model the full application starts to take shape.
If anyone wants a bit more detail on my development process drop me a comment and I’ll write an entry about it, I’m sure it’s not revolutionary, but it seems to work.
Difficulties
I’ve found two main problems with MVP as a pattern.
Starting out can be problematic, particularly if you have traditionally put the majority of your code directly in your code behind with the occasional data access class. MVP seems a cumbersome way to achieve something that you can achieve with fewer classes. It also a little confusing to set up for the first time, where to create objects and in the case of ASP.NET applications when to create them. All I can say to this is give it a go on a couple of small projects to get used to it. It really is one of those times when doing rather than talking gets you somewhere. Just don’t be put off by the first time, it can be tricky to begin with. I’ve started out with my VB.NET template when instructing other people how to build MVP applications by keeping everything in one project. Once the pattern is successfully understood then moving the Presenter and Model out to separate projects isn’t a huge leap. The most useful aspect of the Template I think is learning when and where to instantiate the Presenter and the Model. My first few attempts at doing MVP resulted in a lot of null reference exceptions!
The second issues I’ve found is events. This is mainly a problem for ASP.NET and the page lifecycle, if you are triggering events at the model level and passing the values back by the time it hits the view it can require a bit of thinking about when objects exist and when events are raised at the model level if those objects will still exist. It is a little more straight forward with windows forms although it still requires a reasonable amount of thinking through when considering the flow of information and event handling.
I hope this has been useful. If you have any questions I’ll do my best to answer them. I’ve helped a number of people get started on MVP and have written a number of real world projects myself using the pattern, so I should be able to help. Good luck with your implementations…
