1. 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.
2. 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
3. (“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 there
its easy to define 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.
