Model View ViewModel Presenter pattern in the Kitchen
To better illustrate my self cooked MVVMP pattern I have created the following image
Here chicken is the model and the person is the view. This means that view ultimately consumes the model but before it is in consumable form it has to go through Presenter (i.e. get cooked) and then presented in a ViewModel (plate) to consume from. This is the most sane way of doing things.
Now in a typical MVVM pattern what people do is that they combine the presenter and viewmodel into one thing called ViewModel i.e. they add business logic in the viewmodel instead of separating it in Presenter. So semantically it means that people tend to eat straight from the pressure cooker when the food is ready instead of pouring it in the plate. For them the cooker not only cooks but also serves as the container to eat from.
In MVVMP the ViewModel contains the properties solely for the purpose of data binding on the view and holding references to ICommand . Presenter contains IView and ViewModel references and acts as a command and control center for both.
So yes Tom (the person) can practically eat the chicken directly from the cooker once it is cooked but that won’t be very civilized way of doing things similarly in the world of programming MVVM doesn’t seem civilized to me therefore we have MVVMP (Model View ViewModel and Presenter) pattern.
Categorised as: Programming
[...] This post was mentioned on Twitter by Hasan Khan, Overroot. Overroot said: Model View ViewModel Presenter pattern in the Kitchen http://t.co/aEtZKyd [...]
Brilliant!
Cool..! Nice analogy… :)
I’ve been thinking along these lines too but I’m not 100% sure how to actually implement it. I’m happy with the idea of the Presenter being in charge and being responsible for instantiating the ViewModel and View but would the ViewModel have a reference to its Presenter or would I implement VM to P communication via some loosely coupled messaging or events? If the former then they would all have to live in the same assembly and until now I’ve been keeping my ViewModels in a separate one.
Mackie
As far as your ViewModel only contains properties and ICommand place holders, its fine to keep it in the same assembly as Presenter because then it acts like a contract rather than implementation and there is nothing really to abstract out since there is nothing beyond that point.
In pure MVVM it does make sense to separate out the ViewModels in a separate assembly as you did but in MVVMP its not necessary.
The presenter should not instantiate the view, it should take it in constructor as a dependency (rather interface of it).
My next blog post is going to be about how to implement MVVMP using PRISM and without it.
I look forward to it :)
This guy has had a similar idea but seems to see it working in a slightly different way:
http://billkrat.wordpress.com/2010/12/24/model-view-presenter-view-model-mvpvm/
Re. view creation, I’m fairly new to using DI frameworks (I do have references to Ninject in my solution but I’m not using it much directly). My view is generated dynamically based on some definition data which is an argument of the presenter so I’ll need to look into the best way to do that. I also dabbled with setting the DataContext to be the presenter but I think it’d be better to keep all bindings in the VM and just delegate the appropriate ICommands to the presenter.
I’ve now blogged on how to implement MVVMP here
Hello
See:
http://www.planetgeek.ch/2009/08/30/why-mvvm-model-view-view-model-is-not-enough/
http://www.planetgeek.ch/2009/10/18/agile-ui-development-in-net-table-of-contents/
Daniel
Great minds think alike ;)
I thought I invented MVVMP but you beat me to it.
Good job!
[...] I explained what MVVMP is and then I illustrated how it makes more sense than MVVM. Now I’m going to show you how to implement MVVMP a.k.a. [...]