More on MVC and M-V-VM


There have been a raft of interesting articles and discussions of MVC patterns and WPF.  A practical introduction is here:


http://www.codeproject.com/KB/WPF/MVCtoUnitTestinWPF.aspx


I love the article, but must add I have always struggled with RoutedCommands and CommandBindings.  I think the APIs are too complex for what they do, but more importantly I prefer to route commands through my application model, not through WPF’s element tree.  The Blend architecture contains a creature called CommandManager which makes sure commands get to their destination, and we tend to Databind directly to properties of type ICommand (I love ICommand, just not its implementation in RoutedCommand).


Meanwhile, Dr. WPF aptly summarizes the controversy:  http://www.drwpf.com/blog/Home/tabid/36/EntryID/27/Default.aspx


Basically, I have found everyone agrees you should separate your Model and your View, but the details of the rest depend on technology and personal preference. 


Comments (3)

  1. wekempf says:

    Good post.  You and I have discussed the whole RoutedCommands thing in the past.  I don’t think I ever quite understood why you disliked them, until now.  If I’m reading between the lines correctly, what you don’t like is that you can’t route a command to the Presenter/ViewModel/whatever (well that, and that the RoutedCommand architecture is rather complex).  I can agree with all of that.

    However…

    I still believe RoutedCommands are important, just flawed in design.  I’ve got a lot of experience in Web development and in XUL development.  In both (well, they are related after all) it is extremely important that events bubble.  I absolutely believe that it’s just as important that they be routed (up and down) through the visual tree in WPF.  This allows the UI’s natural heirarchy to effect the behavior.  A simple example would be a RoutedCommand used to display context sensitive help for a complex page.  A top level handler on the page itself would display a help document about the page.  A complex control within that page might have a handler that displayed a different document.  Thanks to the routed nature of the command, we have a single command and simply add different CommandBindings in different places within the visual hierarchy.  I honestly believe this is critical functionality, and so I much prefer RoutedCommands over ICommands.  Well, except that the current RoutedCommand architecture makes it so difficult to put the handler in the ViewModel.

    In general, there are a lot of things in WPF that could use some refactoring to allow for greater extensibility in this area.  Not to mention there’s a lot of things that simply should work "out of the box" with code not in the code-behind.  Hopefully Microsoft can address some of this in the future.

  2. Rob FireGarden says:

    Interesting discussion without reading the controversy. There has always been a longing for that perfect MVP windows / web architecture and It feels like we are all almost here. "The Taligent Programming Model" by Mike Potel still holds truth. Looking forward to this next push in architecture from Microsoft.Net.

    Has anyone else conceived of a code generation architecture strictly confined to the PresenstationCore?

    Rob