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

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.

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

I hope you do some articles on WPF design, there is a big market for them!

Kevin
http://blog.quantumbitdesigns.com/

Can you elaborate what the problems with command binding is?

Florian
http://www.planet-xaml.net

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/

Josh