Julian Dominguez Blog

In this post (of what may become a series of posts if I find some interest from the community) I compare 2 different approaches for separating view code from business logic in order to reduce the untested surface area while doing TDD.

The Passive View pattern

I have been using the Model View Presenter (MVP) pattern (or more specifically the Passive View pattern) for a long time now, both in the Winforms and WebForms worlds.

The main reasons for this? Testability and separation of concerns. As a TDD adopter, I want to be able to unit test as much logic as I can.

Passive View works fairly well, allowing me to keep the view (usually in the form of a user control) somewhat thin in order to satisfy myself without testing it (you know how difficult/impossible it becomes to unit test a UI screen).

In practice, applications written using Passive View end up having lots of boiler plate code for the communication between the view and the presenter. It also makes it very prone to start putting more knowledge on the view than what I’d like, not only for laziness in trying to avoid forwarding messages (that require very simple processing) to the presenter, but also in some transformations needed to keep the presenter agnostic of the specifics of the UI implementation.

WPF templates to the rescue!

In the Prism project we’ve using the Passive View approach also, as a logical step to adopt WPF when you come from winforms / webforms.

In the last time, though, I have been becoming very fond of another approach that is very easy to implement now using the WPF templating and databinding capabilities that weren’t available before: the Presentation Model pattern. This has been also called Model-View-ViewModel by John Gossman / Dan Crevier (if you haven’t read their blog posts on this topic, you MUST read them).

What I would like to add/highlight in this approach is that in WPF you can enforce keeping your view extremely thin by avoiding the use of UserControls or UI-coupled controls. Instead, you can create DataTemplates of your Presentation Model classes, and those model instances are the objects you’ll add to your Window. When your model gets laid out in the visual tree, WPF will automatically pick up the correct template for that model, and render the model appropriately.

This approach relies extremely on data binding, because there is no code behind at all on the views, just XAML markup.

Most of the times I end up deriving my presentation models from DependencyObject to benefit a lot from dependency properties.

In some cases where UI complexity dictates it, the model may derive from Control instead. "What?!? a model deriving from a Control?". That was my first thought when I came to that possibility, but it was highly biased from my Winforms past. Controls (don’t mistake with UserControls) in WPF are totally lookless and do not rely on the UI, so they can be tested in isolation. To render the appropriate view you’ll need to create a default ControlTemplate (compared to a DataTemplate for plain objects or DependencyObjects). One big benefit about using Controls is that you can maintain a WPF logical tree of presentation models (there are some benefits about this which I won’t cover in this post).

I’m planning on providing you with some code samples in the future, but in the meantime guess what: The latest Prism code drop will be including a spike we did using this approach. You should check it out and see how it feels. Notice that this is just a spike and we are only releasing it in order to get feedback from you guys, and see what is the interest on seeing more of it.

A new drop of Prism is out there. If you haven’t yet taken a look at Prism, you should definitively do it.

This last iteration’s goal was mainly about refactoring and making lots of changes that as the framework evolved we were not very comfortable with. We had reached a point where we had so many PostIts in our refactoring wall that we were saving for later, that we decided to spend a whole iteration on them.

You can read the high-level changelog on the Codeplex release page for the drop and Ezequiel’s post, so I won’t repeat them, but I’ll comment on some of them.

• IMetadataInfo (and IMetadataInfoProvider) was removed from the Prism framework.

Previously, the Prism framework was playing a part in connecting some header metadata for a view to the region it was placed in (in some sort similar to what SmartPartInfo was in CAB). This was not flexible enough in the WPF world, where you could use your creativity and designer skills to come with a super cool UI (or at least not the ol’ basic gray tab control).

Furthermore, there is no real reason to provide framework help on this, when it’s easy enough to just use WPF bindings to provide the metadata or title text for the view that gets placed into the region. Don’t worry, is not that you get nothing now when you were at least getting some help before: you will still receive guidance (for now in form of a Reference Implementation and QuickStarts).

• We are now using generic commands (DelegateCommands in Prism) in a more consistent way than before.

You’ll also probably notice a commands proxy class that does nothing else than redirect to a set of static commands. If you look closer at the code usages, you’ll notice that this class is inherited in the unit test projects for mocking purposes, to avoid using the static instances of the commands that would mess up the independence of the tests.

There are literally several dozens of changes and fixes, so please get the latest drop and give us your feedback on it, as we are using your feedback immensely.