15. July 2010 22:54
Microsoft have recently released the VS2010 Visualization and Modeling Feature Pack which brings excellent new capabilities to Dev10. I had blogged previously about the modelling features in Dev10 and was disappointed that there was no capability to generate code from the UML class diagrams. Thats now been addressed in this first feature back release:
The concept of feature packs is slightly different to that of the power tools that we've got used to. A feature pack has more carefully chosen features and is fully tested and supported. Feature packs will also be rolled into future releases of the product whereas power tools(toys) were a more ad hoc.
This feature pack is available for download for MSDN subscribers (Visual Studio Ultimate with MSDN) and you can find out more here.
7. April 2010 15:49
In the second part of this blog posting (part 1 here) I’m going to examine the Model View Presenter (MVP) pattern. We’ll take a look at how the pattern can work, the pros/cons and an example of implementation. Please note that this is one example of how to implement the MVP pattern and this is not the only way you can do it. I am a big fan of this pattern and in a lot of cases this is my preferred way to develop UI’s.
The pattern is separated into 3 elements:
The actual user interface that displays data and receives commands from the user. This could be an ASP.NET WebForm, a WinForm, WPF page etc. The commands are handled by the view, but it passes the command to the presenter which contains the logic. This way multiple views can share the same presenter logic. The only time I put UI logic in the View is when that logic is specific only to that view (e.g. I would not put ASP.NET specific logic in the presenter – I would keep it in the UI).
Marshalls data between the View and the Model and vice versa. Receives commands from the view and performs UI logic e.g. validates and persists model data when a button is clicked.
The domain model representing the data of a particular system. In my example this is in the Business Layer (BL).
- Facilitates automated unit testing
- Allows multiple UIs to share the same presenter logic (DRY)
- Improves separation of concerns in UI code
- Can be implemented in most UI scenarios (WebForms, WinForms, WPF)
- Takes longer to design and implement than a traditional ‘Forms and Controls’ UI.
- Some thought required as to how much UI logic resides in the view and how much is in the presenter. It is more correct to have the logic in the presenter, but in some scenarios it will be more practical and pragmatic to have it in the view.
- Tight coupling between the View and the Presenter (unlike MVVM)
I have put together some sample code which demonstrates this pattern. The code shows how to implement multiple UIs from the same presenter – in this case a WinForms, WebForms and WPF UI. It also shows how to write unit tests against the presenter – in effect giving you a testable UI. Alternatively you could use one of the .NET MVP frameworks out there
Download the code as a VS 2008 solution.
Martin Fowler has proposed two variants of this pattern (Supervising Controller and Passive view)
MVC# – a .NET MVP framework
An excellent Code Project article describing how to implement the MVP pattern.
Any comments or feedback is welcome.
1. April 2010 12:12
I’ve been spending some time recently thinking about UI design patterns and the three main questions that I have been considering are:
- What UI pattern should I use (and when)?
- What are the benefits of using the pattern?
- What the the limitations of the pattern?
Sometimes as software professionals we spend more time thinking about the details of how exactly to implement a pattern ‘correctly’ and forget why we are using the pattern in the first place. For example - is it worth using the MVP pattern for a small app with a simple UI? Will my final deliverable benefit from me having chosen that pattern? I’ve heard developers claim that there is no point in using ASP.Net WebForms because there is a new ASP.Net MVC framework. Why? The motivation here seems to be that “there is something new and it must be better so I’m only using it from now on”.
When architecting software we must always remember to lift our heads from the ‘cool’ details of the latest pattern we are interested in and remember that we are building more than just well structured code with the latest techniques. We are building quality software that must be delivered to spec, on time and to budget. Design patterns should be chosen because they deliver some benefit to the project and not just because they are ‘better’.
I guess the point of what I’m saying here is that if you are choosing a UI design pattern you should know why you are choosing it and what benefits it will being.
Part 2 of this blog post will look at some common UI design patterns and examine where they can be used and what the benefits and limitations are.