Hey!
I haven’t been blogging as much as I’d like to because I’ve been busy writing my Wedding Application. You can find more about it in my previous post but if you’d just like a quick synopsis, in my spare time, I’ve started writing an application around my coming wedding. Being busy with this is not all bad because it’s helped me to revisit a technology I learned about on-site. Let me tell you more…
If you don’t already know about design patterns, they’re essentially descriptions of what works most frequently in programming. They’re based on a lot of the work by Christopher Alexander with his architecture patterns. Now, before you go googling for “software architecture patterns by Christopher Alexander”, you might like to know his patterns are for buildings, suburbs, and other general living spaces: i.e., not software. Although Christopher Alexander’s work wasn’t designed for software, it’s inspired a generation.
Anyway, this post isn’t about all patterns, I don’t have that much spare time; it’s a very large topic. Instead, I want to talk about the pattern I’ve been using for the GUI of my wedding application. This particular pattern is called the MVP Pattern or Model View Presenter.
So, the whole idea behind this model is to decouple the UI controls from the UI logic and from the business model. It doesn’t do this by burying the UI logic with the business model, that would be a step in the wrong direction, but instead, it introduces a new layer. Let me explain more…
The MVP pattern is really about three parts. The first is the Model, the business model. This is where your business logic exists. It’s not unreasonable for the model to be a complete module containing all the non-UI stuff: business logic, persistence logic, etc, etc. It knows how to do stuff, like create records and apply business rules.
The next part of the MVP pattern is the View. This is what you get to see, literally. This is your forms and windows, your dialog boxes and your console screens. Now, what I need to mention here is that it is developed as an implementation of an interface. This is because it decouples so greatly, it allows you to swap and change your views: think of one application with one UI logic yet interchangeably displayed on Windows Forms, WPF, Console, ASP.NET, or Silverlight. The application isn’t changed, the IView (typically) interface is simply implemented differently.
Lastly, the MVP pattern introduces the Presenter. This is where your UI logic exists. It’s actually the driver for the UI and the main conduit between the view and the model. It’s responsible for updating data displays, formatting displays, and notifying the business model of user commands.
What I like most about the MVP pattern is that it makes your UI logic testable. Unlike UI drivers that send window messages to your application, MVP allows you to unit test your UI logic and that’s what I like about it. It’s really early in the development cycle, meaning less cost to fix any defects that are injected in the product at that stage.
You might like to look at more here. You will definitely want to know that Martin Fowler has decided to split the pattern in to two separate patterns called Supervising Presenter and Passive View. Definitely worth the read.
If you haven’t already, I really urge you to get in to design patterns. They really do help with software architecture and enough people know them that you can use them by name in conversation with other software engineers. If you’d like another great resource, try Do Factory, it doesn’t include MVP but it is good none the less and reflects the GoF (Gang of Four) design patterns.
Kind Regards
Glenn
