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!
UPDATE: 1/28/08
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!
Thanks for the kind words, Doc. I’m really glad that you enjoyed my presentation so much. 🙂
Josh
Dr. WPF,
Have you posted M-V-poo yet? I couldn’t find it.
I’m with you and Josh on this and will really be digging into this over the next few weeks. Real world means, we have to deliver high quality, maintainable software in a reasonable amount of time.
I’m looking at this from the business application point of view that has 500 forms, solid business and data layers.
I’m trying to understand “why” I need another class to work with my UI, since the events serviced by the UI all call BLL methods anyway.
All my validation is auto wired to the BLL. The wiring takes place at the control and form level. I’ll be writing a WPF article soon on declarative programming in the BLL that explains all this and provides a single base class that BLL entities can inherit from.
These are exciting times! Cheers!
Karl
http://karlshifflett.wordpress.com/
Maybe someone will come up with a derivated pattern… how about poo-first-pattern 🙂
Can you elaborate what the problems with command binding is?
Florian
http://www.planet-xaml.net
I think you hit the nail on the head with M-V-poo. Everyone knows a model is needed. Everyone knows a view is needed. All that is left over is just… poo.
I hope you do some articles on WPF design, there is a big market for them! 🙂
Kevin
http://blog.quantumbitdesigns.com/
Hey Karl,
I don’t really have any official guidance to post on M-V-poo, other than to say that if you pick an MVx archictecture (mine is closest to M-V-VM… but I call the view model a data view) you should recognize that there is no such thing as a “pure” implementation… at least not yet… and most attempts to force a pure implementation just add complexity to the solution. In that sense, your approach sounds like a step in the right direction. Definitely looking forward to the article!
In my opinion, the biggest reason for implementing the middle layer is to support the requirements of the view that have nothing to do with the data itself. You really don’t want this overhead directly added to the data layer because you might want to share the same data layer with other non-WPF technologies. So a data view (or view model, et. al.) gives you a place to add a “conceptual view” of what will be in the actual view.
But as soon as you say this, the purists out there start clamoring about how the data view is too strongly tied to the view itself and yada yada yada… so I’m hoping that by admitting its poo from the beginning, I can avoid such arguments. 🙂
I think the real test for this architecture will come once Silverlight 2.0 is released. Assuming it supports the same general requirements of WPF around things like data binding, I should be able to easily create a Silverlight view and a WPF view of the same data view. That will be very cool!
Definitely exciting times!
Cheers,
-dw
M-V-Poo hilarious…but I agree it’s impossible to avoid getting some of the muck from your UI mixed in with your presentroller.
Florian…commanding is a perfect example because ICommand is defined System.Windows.Input namespace and resides in the presentationcore assembly. Thus it breaks the concept of removing all reliance on your presentation technology from your controller.
I personally think that ICommand deserves to be in the System namespace. But that’s a different conversation altogether.
regards,
i need this code m-v-poo 4 client deliverable this week it is urgent please give me this poo sample thx by
Some old colleagues of mine use the C.Y.O.A. (Choose Your Own Adventure) pattern. With CYOA, you wrap your entire program in one method and embed your code in a huge tree of “if” statements (even a “switch” statement if they were feeling frisky). Debugging was no longer a chore to them, but more like an engrossed game of Dungeons and Dragons.
Anyways, I don’t think I’ve used an application pattern where I didn’t break the “rules”. Maybe because the pattern didn’t fit or maybe just out of my own ignorance.
I think M-V-Poo symbolizes, that with patterns, one size does not fit all, or maybe that rules [to patterns] are just limitations/loose guidelines. That being said, M-V-Turd is what I’m doing at the moment. 😉
-Jer
Go Josh Go….. Dr nice name, M-V-poo 😀
Devin (the one you know) and I were just discussing Design patterns and M-V-poo came up… so I came and found the article. I must say I’m sold, M-V-poo I think is my new best practice. no more discussions on MVP or pMVP or MVVM or MVWTF its all just MVpoo. Great work Doc.
[…] want to pay homage to the “original” name, or Presentation Model for those Java folks, or even MVPoo for Drs. and folks fed up with the various names, is a UI design pattern. The pattern separates […]
Now I can make my consulting fortune hawking “PDD,” or “Poo Driven Development!”