I just saw a *GREAT* presentation by Josh Smith on using the Model View Controller (MVC) pattern to develop WPF applications. Josh did an awesome job of breaking down the different pieces of the pattern into understandable parts and showing how each fits into a very simple WPF application. And of course, he’s already blogged about it!
Josh just posted this excellent Code Project article explaining his approach to MVC and unit testing in WPF. It is a written version of the WPF Bootcamp presentation that he delivered at Microsoft last week.
The live presentation will eventually be available online in either streaming media or downloadable format and I will update this post with a link.
Those of us who have been writing WPF software for a while have (either consciously or subconsciously) moved to a similar architecture for our applications. Such an architecture allows us to better leverage the power of the platform to separate UI design from the logic that is used to manipulate (or control) a view of the data. There are many different variations of the pattern, including M-V-P (and variants), M-V-VM, or my version, which I’m choosing to call M-V-poo.
Every discussion I’ve seen on these software architecture patterns eventually ends with an argument amongst the purists as to whether specific functionality belongs in the controller (a.k.a., the presenter, the view model, the whatever); or whether the controller should really be allowed to reach into the view; or whether the controller should have any dependencies on a specific UI technology; or ad infinitum.
I anticipate seeing similar debates regarding Josh’s example. My favorite part of the talk was where he gave a nod to the purists and invited them to share such feelings with the caveat that he just doesn’t care.
We all recognize that in a perfect world, there would be a clear delineation of boundaries… but unfortunately we write software in the real world. The cold hard fact is that there are definitely aspects of WPF (especially around things like commanding) that make it impractical to completely separate the presenter from the view. The same thing can be said about every other UI platform I’ve seen thus far. But WPF definitely gets us a lot closer to a perfect world than prior Windows technologies.
This leads me to my new pattern: M-V-poo (because really, there just aren’t enough architecture patterns! ). My pattern acknowledges that there may indeed be “poo” within the view model, but it tries to minimize that poo (or at least make it less stinky) whenever possible. Please feel free to use this pattern royalty free!