Prism 2.1: MVVM Vs MVP

Now it’s not a no brainer! Prism 2.1 has direct support for the MVP pattern which is great for those projects that require a more coupled and rigid solution where you can test the binding between the presenter and view and their interactions. However, that’s a whole heap more code that you would have to write which just disappears when using MVVM due to its very decoupled nature.

But as we know; decoupling is not always a good thing. A few people have pointed out to me that they have many problems with MVVM when people change bound property names but don’t change the corresponding views. For complex applications, that can be a big problem. I argue that if you are going to use MVVM, then automated user acceptance tests become more relevant and important. If that is not an option, then perhaps you should consider a more tightly coupled pattern than MVVM to give you that compile time checking that many have come to rely on.

For me, MVP with WPF is like a step backwards. With MVP, suddenly it takes far longer to write and change my application and I have much more plumbing code than I would with MVVM.

Implementing MVVM within Prism 2.1 is actually very easy. In fact, it’s easier with Prism than without because Prism comes with all the IOC goodness that is required for MVVM to be implemented elegantly.

Prism has a Region manager which is put into the Unity container at runtime. All I have to do is inject the IRegionManager interface in the relevant classes as I normally would and instead of instantiating a View and adding it to the required region, I add the view model to the region and rely on my usual DataBindings to take care of the View Model- View associations.

CodeProject