Richard Leggett on New Media

Yes, another pattern, but I’ve just come across a great post on the M-V-VM pattern and it’s a good one to share. I was introduced to the V-M-VM pattern just under a year ago by an outstanding .NET dev when we worked together on an RFID/database powered WPF application (pics), and I have to admit it worked *really* well, I was utterly convinced by this concept with regards to WPF developement. (Link to article at the end of this post.)

So what is it? Very much a spin on MVP, it’s a descendant, to some extent, of the classic MVC pattern. The aim being to create very simple View classes that are separated from the Model by another entity. Not the controller per-se (more on that in a moment) but a “ViewModel", a model specifically for a View. The View’s sole data source resides in its ViewModel, this can do things like perform validation, turn raw data into visually relevant data (the classic Martin Fowler-esq example being a thermometer view that changes the number value displayed from blue to red when the temperature goes over 20 degrees - resolving the issue of why store this colour in the [real] model when only the View cares), it also bridges the View to the Model whatever that might be and however that might change in future.

Follow up:

This may sound somewhat redundant, but in actuality it couples up very nicely with some of the current RIA GUI platforms’ built in features for commands and data binding. This is where it excels in fact. Here we’re talking about the dataProvider/data-binding mechanism in Flex, and the DataContext/data-binding mechanism in WPF and Silverlight. I must say the latter is a little more powerful due to the “cascading” nature of DataContexts in WPF/Silverlight, which results in less wiring code, but ultimately around the same amount of code in other places because the .NET stack is far less dynamic (e.g. Converter classes in place of in-line function calls in binding expressions). We’re also talking about the built in “Controller” element provided by Command mappings in WPF/Silverlight, and the similar mechanism provided by a framework like PureMVC/Mate/Cairngorm, or indeed a roll-your-own solution utilising the event bubbling system in Flash/Flex.

Couple MVP with Dependency Injection and you’re onto a lean application, and strict code separation. Admittedly this introduces a learning curve but that curve pays for itself ten times over in even the smallest of projects if you ever intend to maintain or add to them. You often here these patterns make things “easier to test". That’s great, but for me I think “easier to test” although well worthwhile in itself, is simply a by-product of an easier to read/use/maintain app anyway.

The reason this pattern is so much more relevant now is that it really comes into its own in GUI programming. I’ve often thought GUI programming requires different patterns to both non-gui (command line) and also traditional Web development, different applications of MVC. We really should keep our views clean, our class relationships uni-directional where possible (forbidding circular references entirely) and our class interfaces lean and relevant because we have to contend with continually varying state, a context to maintain, asynchronous user actions and regular cleanup to perform.

That’s just a little background, but this article by Jonas Follesö explains things in detail. If you primarily work in Flash/Flex like me, it’s still relevant even though he’s using WPF to illustrate things here.

Link to the article.

And finally here’s a request for Generics in AS4. I know it’s a potential can of worms and might further exacerbate the situation of AS3 being “too hard” for people to make the “leap", but it enables some really neat tricks to be done with typing intact.