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:

• Generate code from UML class diagrams
  Generates C# code directy from a UML class diagram using text templates.  The generated code can be customised by editing the templates.
   
• Create UML class diagrams from code
  A simple drag and drop will create a UML class diagram from your existing code.
   
• Import UML class, sequence, and use case elements from XMI
  XMI (XML Metamodel Interchange) is a standardised XML format which describes UML models.  This format allows the interchange of UML models between different software packages.  Currently there is only support for importing XMI and the export functionality will follow in a future feature pack/power toy.
   
• Create and view links from work items to model elements
  If you're using TFS this could be useful for work item tracking.
   
• Generate dependency graphs for ASP.NET Web, C, and C++ projects
  The ASP.Net web dependency graph will be useful, and I'm sure C/C++ folks will now be happy to be included.
   
• Create and validate layer diagrams for C and C++ code
  Again, I'm sure C/C++ devs will be happy to have this feature available to them.
   
• Write custom code to create, modify, and validate layer diagrams
  I can see layer diagram extensibility being useful to some architects.  You can now write and deploy (VSIX) code to customise how layer diagram are used.

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. 

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:

View
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).

Presenter
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.

Model
The domain model representing the data of a particular system.  In my example this is in the Business Layer (BL).

Pros

• 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)

Cons

• 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)

Sample code
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.

Related information
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.

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.