MVVM != MVP in CAL. Right?

Topics: Prism v1, Prism v2 - Silverlight 2, Prism v2 - Silverlight 3, Prism v2 - WPF 3.5
Oct 8, 2009 at 11:18 PM

From my understanding, MVVM requires a decoupling of the View from the ViewModel.  This is most often accomplished by setting a DataTemplate for a ViewModel to a View in a ResourceDictionary.

On the other hand, MVP requires the ViewModel to either resolve a View, accept a view from the constructor through injection, or opening up a public View property for some other class (i.e. Module) to set the View on the ViewModel.  I like using the injection approach.  Unlike MVVM, CAL recommends: the ViewModel gets a reference to the View, the ViewModel sets the Model property on the View.  The View, then, has a little code behind for the ViewModel property... the getter returns the view's DataContext as a ViewModel type (via casting) and the setter simply sets the DataContext of the View.  This means that the View "knows" about the ViewModel because it has a property of type ViewModel.

I would like to use MVVM in CAL/Prism/Composite WPF because I like the ModuleCatalog, Services, Events, Bootstrapper, and other very useful concepts in CAL/Prism/Composite WPF.  However, I REALLY want to use MVVM to decouple my View from the ViewModel.  So here's what I did...

I created a simple Shell with a region in the main application.  I created another assembly to act as a module.  In the module's initialize method, I register and resolve a ViewModel instance and add it the the region.  Yes, that's right, I add a ViewModel (not a View) to a region.  [You'll usually see ViewModel.View added to a region.] 

I also have a ResourceDictionary in the model that gets added to the the application's MergedDictionaries.  In the ResourceDictionary, I simply set the content of a DataTemplate for the TargetType "MyViewModel" to the "MyView."

The ViewModel is, in fact, getting added to the Region.  The MergedDictionary does contain the DataTemplate.  BUT, the View is not being rendered.  Any ideas why?

To test to make sure it works in the MVP pattern, I added a ViewModel property in the code behind to the View, added the View in the constructor of the ViewModel for DI, and set the View's ViewModel property in the constructor of the ViewModel.  (Plus, I commented out the DataTemplate).  I also, of course, added a registration of the view in the Module and added the View (instead of the ViewModel) to the region.  And, as expected, it worked.

How do I REALLY implement MVVM with CAL/Prism/Composite WPF?

Oct 9, 2009 at 8:14 AM

Hi, Guy,

I think you misunderstand, MVP and MVVM are the same, although the implementation is different in coding format.

MVVM can do antthing that MVP can do, so do MVP.

I think your memtion is the difference between view-first and presenter, or maybe result in the difference between view discovery and view injection.

Oct 9, 2009 at 2:49 PM

I guess the the operative word is "implementation."  In one implementation, the View "knows" about the ViewModel, and vice versa.  In the other, the View does not "know" about the ViewModel, and the ViewModel is rendered using a DataTemplate to associate a ViewModel with a View.

Although the intentions are the same, to me, these are not only completely different implementations; they are different patterns.  One major element of a pattern knowing or not knowing about another major element of a pattern is helps to define the pattern, or at least its nature.

Nevertheless, whether there're different patterns or the same patterns with different implementations, the point is that I would like to add a ViewModel (not a View) to a region and use a DataTemplate to determine how the ViewModel should be rendered by a View.  Any experience out there with this?  It'd be like combining the CAL reference implementation with Josh Smith's MVVM example on MSDN magazine.

I messed up the subject line for this discussion, I really did not want to get into a patterns discussion.  I now realize there is a pretty heated debate about MVP/MVVM.

Could someone help me out with implementation, whether or not MVP and MVVM patterns are the same?

Oct 9, 2009 at 4:22 PM

One thing I did notice in the InnerAdd method on Region is the code attempts to cast the View to a DependencyObject.  Since ViewModels are rarely dependency objects the RegionManager attached property is not being set.

So, I made my ViewModel inherit from DependencyObject just to see what would happen... and... nothing.  Same results.  Doggone it!

Oct 13, 2009 at 10:45 PM


You can check this blog post from Julian Dominguez that explains how to use DataTemplates with Prism (although it is for Prism-v1 the general concepts are still the same). Take into account that this is one of the ways to implement the MVVM pattern. There are other ways to implement this pattern (not necessarily making one more pure or better than another) which might vary depending on your requirements, comfort and preferences. As for the difference between MVP and MVVM, you can think of the ViewModel as kind of a "bindable presenter".

You can read the following blog post from Glenn Block which talks about this:

As the above explains there is not a single way to do MVVM. Most of the Quickstarts and the RI use the MVVM pattern without data templates, so you might find some of those examples useful if you follow that approach.

Please let me know if this helps.

Damian Schenkelman

Aug 22, 2010 at 9:22 PM
Edited Aug 22, 2010 at 9:25 PM

MVP and MVVM are not the same hence the reason for having two patterns that solve the same problem. The fundemental difference is in MVP both the presenter (ViewModel) and the view know about each other always (via interfaces) and is typically used with WinForms as WinForms does not have the advanced binding that WPF does. In MVP you'd normally have quite a few different methods on the view interface that accepts data from the presenter. WPF solves this with MVVM with advanced databinding techniques so the presenter no longer needs to do this. In MVVM, generally the View knows about the ViewModel but the ViewModel doesn't know about the view. In the example Prism code, MVP is used but the the added benefits of the view binding to the ViewModel. I'd say in Prism/CAL the pattern used is a mix between MVP and MVVM.

I do like Prism, I think it brings a lot, and separation of modules is great. There is one thing that is nasty though. That is injecting Unity into the module in order to register module specific classes couples you to the unity container somewhat. It would be better perhaps to extend the ServiceLocator to allow registrations as well as resolving - perhaps a new pattern called ServiceRegistrar!

I almost forgot to mention, why are you so concerned about the view knowing about the ViewModel, it should be the other way around, hence the whole point of these separation patterns that then allow you to not only test your view models independently of the view, but also code reuse independent of the view used.