Overview of the ModelView – ViewModel (MVVM) pattern and data-binding
In my own learning of WPF or any technology that I learn, I use the same approach and design principles that I would for a technology I know inside out. I have used winforms for years and I would be modest to say I know how to design a winform application the right way. It would be the approach I would use if I was developing an application in java swing. I would at the forefront of my design use the “model view controller” (MVC) pattern. The MVC pattern has been around since I was born and has been discussed and debated to death over the years. MVC aside I would use a number of other design patterns that fit the bill for concern situations. For example: I would use command objects to do certain actions which could be wired up to menu items and/or buttons.
Model View Controller
The MVC pattern is a compound pattern, meaning that MVC is made up of other design patterns used together. MVC is made up of the “Mediator” and the “Observer” patterns (I and not going to discuss the details of these patterns as I want to keep to the subject matter, for more information on this patterns I recommend the Gang of Four web site and I might put a post together in the future).
Although MVC is a well established pattern, I have read other blogs and stuff in forums and the opinion of what MVC is, is very mixed. MVC in the .NET world seems to have become more wide spread over recent years which is good but MVC is not just about “Separation of Concerns” which some people I have worked along side believe. I can not remember where I got this from but the rules I follow are:
- Model = what it is.
- View = what it looks like.
- Controller = what it does.
MVC is a pattern and as such is a guideline and the implementations of the pattern vary. Variations of MVC exist like “Model-View-Presenter” (MVP) and “ModelView-ViewModel” (MVVM). In a very brief explanation:
MVC – The view sits at the top of the architecture, the controller sits below the view. The model sits below the controller. So the view knows about the controller, the controller knows the model. The view is notified when the model changes.
MVP – The controller is replaced with a presenter. The presenter sits at the same level as the view. The presenter listens to the events of both the view and the model and mediates the interactions between both the view and model.
MVVM – The controller is replaced with a view model. the view model sits below the UI layer. The view model exposes the data and command objects that the view needs. You could think of this as a container object that view goes to to get its data and actions from. The view model pulls its data from the model(s) below.
I read a blog by Josh Smith on “the code project” once where he talked about MVC and WPF and he stated “lower the flamethrower”. I echo his comments.
If you put ten software architects into a room and have them discuss what the Model-View-Controller pattern is, you will end up with twelve different opinions. … Some of the purists out there will inevitably have qualms with what I refer to as “MVC”. Feel free to leave a flaming comment on the message board at the bottom of this Web page. I will gladly entertain different perspectives on what MVC means, but keep in mind that I do not care.
Data-binding
The word Data-binding used to bring back bad memories of using data-binding in older technologies. In Winforms .net 2.0, it was not perfect, it was ok for simple things like binding data grids and text boxes and drop down boxes but using a date time picker was painful. The .net framework contains a number of interfaces and classes (“system.componentmodel”) that allowed you to implement better data-binding support in your own objects. Using a custom implementation of the observer pattern with a hybrid of the data-binding interfaces was more desirable in winforms. (the memories, the pain).
But in WPF, no need to be down about data-binding, because it is excellent. Though it has a learning curve.
Data-binding is in its own right an implementation of MVC. the view are the controls that are shown in UI. the model is the object you are binding to and the controller is the data-binding component. I think its important to think about data-binding in this way.
Why is MVVM different
I believe that MVVM pattern was developed by some Microsoft developers a few years ago when developing Expression Blend. The main difference with MVVM to MVC is that the ViewModel is built to serve the view and provide the view with the data and commands it needs. The viewModel is not a general object that could serve different views but is bespoke for each view. For the TDD’ers out their its easy to defined the behaviour of a viewmodel and test using a test first approach. The ViewModel is a model for the view. And the real power comes in when you bind your ViewModel to your view in WPF.
The key thing to remember is that you have one and only one ViewModel per view. The view model communicates with the model (business logic, services whatever below it). The view does not need to know about any else in your architecture. Another major plus point is that you do not any code behind your view and the data-binding deals with the communication to the view model and what ever the view model exposes.
Thats it for a quick overview. I have a draft post that i am working on that will put this into concrete code.
Your blog is interesting!
Keep up the good work!
AlexM
August 15, 2008 at 9:57 am
Russell:
After reading a number of posts on mvc, mvvm, mvp ….it is refreshing to read your post, which summerizes the differences nicely.
My thought is that the differences between these patterns are not that significant to warrant different names and whoever have added mvp or mvvm are just packing old wine in the new bottle!
why can’t things be left at mvc with a small note saying: In wpf, the control of mvc is replaced by the binding component.
jas
August 15, 2008 at 4:07 pm
[...] Recent public urls tagged “databinding” → Overview of the ModelView – ViewModel (MVVM) pattern and data-binding [...]
Recent URLs tagged Databinding - Urlrecorder
October 16, 2008 at 1:32 pm
I have question
Everything is fine when “Model” has just one collection.
But when “Model” has more than one collection and “Veiw”
uses “Canvas” to present all objects from all collections.
Should “ViewModel” combine all objects in one “Common collection” to simplify data binding?
Or to avoid extra “Common collection”
Is it better to change “Model” and put everything in one collection.
Ghennadii
November 11, 2008 at 5:53 pm
Ghennadii, thanks for the post. To answer your question, your ViewModel is like a fascade, it can bring one of more models together and expose information to the view.
For example, if you have a view for “customer details”, you could have a collection of customers displayed in a ListView plus a section of your view so you can edit the details (common master-detail pattern). When the user select a customer in the listview the selected customer information is displayed in the edit section of the view. Some of the information about the customer could their “Title” (mr, mrs, dr etc) and “Order”. The view model for this view would expose a collection of customers (CollectionView), a collection of “Titles” and “Order”. So you have 3 different collections.
Now in the view, when the view is created, set the datacontext property in your view to the instance of your viewModel. In the xaml you would bind to the right properties on your viewmodel. Use the viewmodel to bring all the required model(s) together into one specific object for your view.
Hope this helps
russelleast
November 11, 2008 at 10:00 pm
I would like to be a little clear.
View is graphis surface – canvas.
To simplify “Model” let’s say
“Model” has collection of rectangles and collection of lines
no any reason to put all objects in one collection they are very different.
View binding data in “ViewModel” and I do not understand how “ViewModel” should look like in that case?
What I have done so far – all objects derived from base object
in “VeiwModel” I created common collection put everything in one collection and bind “View” to it.
It works.
But I do not like that. I do not like extra collection. I have to support it.
Simple question: Do I have to MVVM pattern or I have to use something else?
Or I’ve done something wrong.
Ghennadii
November 12, 2008 at 4:58 pm
why not partial class to build the ViewModel?
because the definition of viewmodel classes have some definition of the data classes of datamodel , why not try to reduce some work, extending or making partial classes of the datamodel. completing them with command and etc.
Nuno Cruz
November 25, 2008 at 2:04 pm
Nuno, I am not sure i understand your comment. Views, view-models, data models and commands all have different responsibilities. Where do partial classes come into this?
russelleast
November 27, 2008 at 9:32 pm
I think he means that why not extend the data objects into viewmodels by using partial classes.
Yogesh
December 1, 2008 at 5:07 am
data models and view models are different beasts. a single view model could aggregate different types of data models.
russelleast
December 1, 2008 at 11:09 pm
Good work! Thank you!
I always wanted to write in my blog something like that. Can I take part of your post to my blog?
Of course, I will add backlink?
Sincerely, Timur I. Alhimenkov
Timur I.
January 28, 2009 at 2:19 am
Timur, Of course you can, thanks for the kind comment.
russelleast
January 28, 2009 at 10:15 am
Thanks for this article. Each time I read more about MVVM a little more of it sinks in. One of the things that our team has been struggling with has been the connection between the ViewModel and the Model – more specifically, is it common to use the Repository as the Model for the ViewModel? If you make a change in your View which updates the VM through databinding, do you in turn make this update to the Model (Repositiory) as well? If some views use some of the same data from the Model one would definately want these views to show the same data. Does this mean the Model is bound to the ModelView. I guess I’m really having trouble understanding that piece of the puzzle.
Thanks again for your informative work here!
Bill
Bill Campbell
January 31, 2009 at 2:24 pm
[...] folgende Beispiel unter Verwendung von MVVM (Model View ViewModel) Design Pattern. 100% [...]
DataBinding WPF - MVVM Pattern | Biggle's Blog
February 9, 2009 at 9:56 am
Does it make any sense to use MVVM for WPF UserControl / CustomControl?
Ivan Onuchin
March 17, 2009 at 7:48 pm
Ivan, yes it does make sense. I have on complex views, spilt my view up into controls and then use a “micro viewmodel/controller” for that control. Plus my main view will know about the “mirco viewmodel/controller”s. It also helps keep your classes small.
russelleast
March 18, 2009 at 11:09 pm
Russel, thanks for answer. Now I have another question. If MVVM is good for WPF user control, then how to implement this control
properly.
The problem that I see is either we have to duplicate properties of ViewModel (VM) in the View, or we have to provide access to VM for
the user of UserControl… I belive both of these options are not good and I don’t see another option…
Let me explain both options in details:
Imagine, we have control ‘MyControl’ which has corresponded view model ‘MyControlVM’:
class MyControl : UserControl
{
private MyControlVM _vm;
…
}
Let’s say MyControl should have property ‘Value’. For example Value is evaluated when mouse moving over MyControl. In accordance to
MVVM pattern: the property Value should be the part of VM.
class MyControlVM
{
public double Value
{
get { … }
set { … }
}
}
User of MyControl must have access to this property.
1) The first option is to provide corresponded property (and event handler for PropertyChanged event) in MyControl:
class MyControl : UserControl
{
private MyControlVM _vm;
// Duplicate property
public double Value
{
get { return _vm.Value; }
set { _vm.Value = value; }
}
public MyControl()
{
_vm = new MyControlVM();
// Subscribe for VlaueChanged event of VM.
_vm.ValueChanged += new ValueChangedHandler(this.VM_ValueChanged);
}
private void VM_ValueChanged()
{
// Notify all subscribers for ValueChanged event of MyControl.
}
…
}
I think first option is not good, because View has duplicated code for wrapping corresponded properties of VM.
2) The second option is to give user access to VM and let user directly use properties (methods, events) of VM. In this case:
class MyControl : UserControl
{
private MyControlVM _vm;
public MyControlVM VM
{
get { return _vm.Value; }
}
public MyControl()
{
_vm = new MyControlVM();
}
…
}
This seems to be much simplier, but the problem is that user of MyControl should know about implementation of control. For example somewere in C# code:
MyControl mc = new MyControl();
mc.VM.Value = 123.456; // Why user should know about VM…
and it could be even more challenging to access ‘Value’ property in XAML.
The second option does not look as option at all.
My question is how to implement such properties properly?
Thank you.
Ivan Onuchin
March 22, 2009 at 6:12 pm
Ivan, I hope I can help with your problem. I would create a duplicate properties as you put it. My reasons are this are:
1. The users of the control should not need to know about viewModel so no need to expose it. The outside world doesn’t need to know. This is a point that you have already made.
2. Having your view simple delegate to the view model is a simple and clear behaviour, that to maintain this is easy and it would be clear to other developers if they looked at this code.
3. Another way to see it, if you have an textbox on your view, you would bind it to a property on your viewmodel, you are doing the same thing.
I didn’t like the second option. the view is a representation of your model. From a maintainence view point, you could refactor your view model and minimise your changes to within the control, where exposing its published interface could be painful to change.
Again I hope this helps.
russelleast
March 22, 2009 at 8:57 pm
[...] http://russelleast.wordpress.com/2008/08/09/overview-of-the-modelview-viewmodel-mvvm-pattern-and-dat... [...]
MVVM: Great - another acronym. « Silverlight Beginner
March 31, 2009 at 8:08 pm
Hi Russell,
Could you please please tell me the differences between MVP pattern and MVVP pattern?
Thanks,
Ramprasad.
http://www.dotnetdreamer.com
Ramprasad Navaneethakrishnan
April 2, 2009 at 6:36 pm
Personally, I haven’t heard of the MVVP pattern. I have google’d it, but the context is talking MVVM pattern with silverlight.
russelleast
April 2, 2009 at 9:54 pm
Sorry. It was a typo
My question is “differences between MVP and MVVM”
Thanks,
Ramprasad
Ramprasad Navaneethakrishnan
April 3, 2009 at 2:04 am
Ramprasad, to hopefully answer your question. In MVP, the presenter is in control of the view and has knowledge of the view. Compared to MVVM, the view is bound to the ViewModel.
MVVM is a tailored implementation of the presentation Model pattern (that M.Fowler has blogged about) for WPF.
Although MVVM is all good, I now favor rolling my own MVP implementation, so that i can build my presentation logic the same for any view technology then i can simply swap the view technology. ie, Winforms to WPF to silverlight etc.
Hope this helps
I hope
russelleast
April 3, 2009 at 1:31 pm
[...] http://russelleast.wordpress.com/2008/08/09/overview-of-the-modelview-viewmodel-mvvm-pattern-and-dat... [...]
Summary 06.05.2009 « Bogdan Brinzarea’s blog
May 5, 2009 at 12:45 pm
Hi Russel,
good to see the patterns explained in a mere few paragraphs; great summary.
i’ve been wondering about MVVM and how things could be made easier.
having to make duplicates of the properies in the ViewModel of the Model does sound the way this pattern is going, but to be honest, I don’t like it.
Too much copying of code, it’s tedious and error prone.
however i was thinking.. how about Linq to objects? where does this fit in? (does it even fit in?)
could it be possible to simply use a mere Linq select statement on the Model it and create a dynamic, yet typed, ViewModel?
have you considered this scenario?
(to be honest i haven’t tried it yet)
Herre Kuijpers
August 16, 2009 at 10:14 pm
Thanks for the comment. I understand why you don’t like having the same properties in the model and the viewmodel. This has become more common with these days with domain entities, message objects and up to the presentation models also have the same properties. Each one of these types resides in its logical layer (domain, tranport, UI). The transport (message object) will be used by a mapper or some method that maps the data from the message to one of the other types (“domain entity” or “presentation model”). This is done to reduce the coupling.
So the trade off is: do you want to have low coupling where you could refactor/rewrite/replace parts of you domain without having to change code in the ui. Or do you want to share types across your application. Personally I choice “low coupling” which means types need to be mapped as data is passed between layers. It does involve more code which is annoying. but i believe its worth it in the long run. As for linq for objects. I used linq in my mappers, but i still used strongly typed objects.
russelleast
August 17, 2009 at 1:17 pm
Very Nice post and briefing about the MV… patterns indeed. Great job…Keep posting…Thanks.
Shyam
August 20, 2009 at 1:28 am