.NET & Funky Fresh

Syndication

News

  • <script type="text/javascript" src="http://ws.amazon.com/widgets/q?ServiceVersion=20070822&amp;MarketPlace=US&amp;ID=V20070822/US/bluspiconinc-20/8001/8b68bf4b-6724-40e7-99a5-a6decf6d8648"> </script>
MVVM Study Part 2 – “View of the Model” or “Model of the View” ?

As a follow-up to my last post on MVVM, I want to further investigate the ViewModel as a concept.  In commenting on my blog, one reader describes a ViewModel as “a UI oriented abstraction of the model.”  In that sense, he is saying that a ViewModel (VM) is simply a contextual “View of the Model” and that it is confusing to think of it in any other way.  However, when we construct a VM, we do so with the explicit intent of creating a public surface area that is easily bindable and supportive of the UI itself.  Therefore, the public properties and methods/commands exposed by the VM tend to form a “Model of the View.”  How do we justify these two views?  Are they really at odds with one another or are they merely two sides of the same coin?

Confusing Abstractions

One reason VM is confusing stems from its frequent use as an Adapter, where it enables the incompatible interfaces of the UI and domain model to talk to one another.  However, using a VM for this purpose is mixing concerns.  A better solution would be to have an explicit Facade/Adapter/Bridge handle communication between layers, freeing the VM to vary independently from the domain model.  When I’ve failed to make this distinction in the past, I’ve been burned…bad.  Nevertheless, even if your VMs do operate like an extremely intricate adapter, it’s often quite unhelpful to think of the problem in this way.  Doing so can lead you to miss the realization that a VM has its own set of concerns, which primarily center around supporting the UI, not abstracting the domain.  That is to say, we don’t build a VM for the purpose of abstracting the domain model, we build it to power the UI.

How I Think

When I’m constructing a system, I prefer to think of the VM as a state machine with the View being a visualization of the current state.  The user interacts with the View, causing “messages” (actions/commands/bindings) to be sent to the VM.  The VM receives and delegates or interprets these messages, which may or may not result in state changes and may or may not result in domain model interaction.  (I’ll discuss what these state machines look like more in future posts.)  The important thing to remember is that the VM is in control; the view makes “suggestions,” but the VM decides what happens when.

The Flip Side

So, for me, the most helpful way of thinking of a VM is as a “Model of the View.”  But, is there value to the notion of “View of a Model?”  I had to go back and look at concrete code samples from past projects, consider what we did, why and what did or did not work before I could settle on an answer I feel confident about.  I saw code that I wrote two years ago in which I mixed adapter qualities with the view model rather than carefully thinking about modeling the view’s behavior.  It was hideous.  I’m not sure what I was thinking, but I wasn’t creating a “Model of the View.”  Then I looked at NHProf’s code which has an explicit bridge (IBackendBridge) and a structural VM, whose implementation was easy to adapt and extend over the coarse of major architectural change.  It’s code has remained relatively simple and concise while delivering a rich feature set.  Here’s what I have determined.  If your view model happens to look like an abstraction of the domain or “View of the Model,” that shouldn’t surprise you.  It is a natural consequence of that fact that the entire presentation layer of your application is at a higher level of abstraction than the domain model.  From time to time you should think of your VM in this light.  It’s likely that doing so will reveal some implicit concepts in your domain which need to be made explicit.  This happens because the VM closely models exactly what the users are doing.  So, there is value in thinking in this way, but this value is completely different than what is gained from trying to model a view.

Summary

When building your VM, try to think of it as a “Model of the View,” but when building your domain model revisit your VM, trying to see it as a “View of the Model” and ask yourself if the VMs implementation has any implications for your domain.  Naturally, this really only works when utilizing an iterative design methodology…


Posted 08-02-2009 5:38 PM by Rob Eisenberg

[Advertisement]

Comments

Glenn Block wrote re: MVVM Study Part 2 – “View of the Model” or “Model of the View” ?
on 08-02-2009 6:51 PM

Nice post Rob.

In thinking about this more,  for myself "Model FOR the view resonsates better", in a similar fashion to the Presenter being an implementation detail of the view.

The ViewModel services the view providing it data and behavior, it doesn't necessarily match the structure of the view one to one, though certainly there is a relationship.

I think your right on about the approach though, it greatly diminishes the value of VM to think of it only as a simple transformation of the domain model.

Keep up sharing!

Glenn

9eFish wrote MVVM Study Part 2 – “View of the Model” or “Model of the View” ? - .NET & Funky Fresh - Devlicio.us
on 08-02-2009 9:59 PM

9efish.感谢你的文章 - Trackback from 9eFish

Phil Cockfield wrote re: MVVM Study Part 2 – “View of the Model” or “Model of the View” ?
on 08-02-2009 11:47 PM

I agree, "model of a view" resonates more clearly with me too.  

I appreciate the pointers to the "Adaptor / Facade / Bridge" pattern for working a domain model into something more palatable for a VM to operate with (if and when you're finding that is necessary).  That will be useful to keep top of mind whilst trying to ensure all the varying concerns all cleanly isolated and separated out.

Thanks Rob.

Ian Randall wrote re: MVVM Study Part 2 – “View of the Model” or “Model of the View” ?
on 08-03-2009 2:52 AM

I agree with Glenn - I think I've always thought of the VM (at a subconscious level) as the Model *for* the View; thanks for making me think about it the other way round too... I can feel a code review/refactor coming on :)

Ward Bell wrote re: MVVM Study Part 2 – “View of the Model” or “Model of the View” ?
on 08-03-2009 3:08 AM

I'm buying what you're selling here.

If I wanted to put a slight "ViewModel" first spin on it I'd say that the VM should model what you want the View to be doing ... without dictating precisely how the View does it. It would be as if you wrote the VM first with no preconceptions about how the View should actually look.

Personally, I've never brought this off. I'm always tweaking the VM to make it support a particular view. In this way it becomes "an implementation detail of the view". But I still find it helpful to think of the VM as driving the View specification... and this is what it means to say that the VM is an abstraction of the View

I see your point about the "flip side". We only _think_ we have disembodied Domain Models. In fact, it is very hard to define a Domain Model apart from how users will interact with it. I'm not sure why we try so hard.

For example, do we have rules about how to update accounts that are really independent of how real people go about updating accounts in the application? Do accounts sit in some antiseptic chamber free of human contamination guarded by divine rules? Or do we come to understand what "account" means through interacting with them via a UI?

If you think that any of our understanding of the domain comes from crafting the UI, then you will agree with Rob that the VM can be, secondarily, a "View of the Model".

Ryan Cromwell wrote re: MVVM Study Part 2 – “View of the Model” or “Model of the View” ?
on 08-03-2009 9:17 AM

"think of the VM as a state machine with the View being a visualization of the current state"

I think that is an excellent way to describe and position your mindset while working on this layer (whatever we all decide to call it).  

Mike Murray wrote re: MVVM Study Part 2 – “View of the Model” or “Model of the View” ?
on 08-03-2009 11:40 AM

I think it would be helpful for me if you were to further explain this distinction in context of some concrete implementation (even if it's a little contrived).

Thanks for the post.  Hopefully I can wrap my head around the concept.

Rob Eisenberg wrote re: MVVM Study Part 2 – “View of the Model” or “Model of the View” ?
on 08-03-2009 12:36 PM

@Mike

It is a bit *abstract* isn't it ;)  I'm planning to get more and more concrete as I progress through this little series.  There's so much to talk about, actually.  Please hang in there.

George Stevens wrote re: MVVM Study Part 2 – “View of the Model” or “Model of the View” ?
on 08-23-2009 1:49 PM

Concerning the Adapter role of the ViewModel -- I've found it immensely helpful to use the concept of "Display Models" as those objects and/or collections which the ViewModel contains and presents to the View for data binding.

In my work, DisplayModels consist of data from the Business Objects of the DomainModel, plus other stuff that is highly useful to meet the display requirements of the View.  Most recently this "other stuff" is 1) Data Annotations for PCOOs  and 2) wrapping ADO.Net Data Service objects in a Display Model object (using object composition) so as to use Data Annotations in the DisplayModel but not in the composed (wrapped) Data Service object.  Silverlight 3's Data Annotations can be hugely time saving aids in the Presentation Layer.

The Display Model perspective has aided me greatly in separating the concerns of presentating the domain model data and ideas from the utility of having a clean, useable, general domain model that is not cluttered with presentation aids like some (but not all) of the Data Annotations elements.

I support being very specific about "the Model" since it is a fuzzy, confusing, way too abstract concept for implementing an MVVM pattern.  

Bottom line -- The ViewModel contains objects whose main purpose is to be displayed by the View.  Let's call them Display Models (or something like that) and give them what ever behavior and attributes necessary to make their display easy, loosely coupled, and maintainable!

David Nelson wrote re: MVVM Study Part 2 – “View of the Model” or “Model of the View” ?
on 08-24-2009 6:51 PM

This leads to an interesting question that hadn't occurred to me before. Can we create an analogy between V-VM and WPF controls? That is, Control:ViewModel::ControlTemplate:View? After all, one of the much-touted benefits of WPF is the separation of behavior from presentation, which is essentially the same thing that View/ViewModel separation is doing.

If I'm not totally off track here, the natural follow up is, have we missed an opportunity to harness the relationship between Controls and ControlTemplates to implement View/ViewModel? Is such a thing even possible? If it is not possible now, could it have been if that design had been included from the start of WPF, and is there any value in trying to evolve the design in that direction?

Rob Eisenberg wrote re: MVVM Study Part 2 – “View of the Model” or “Model of the View” ?
on 08-24-2009 10:44 PM

@David

You are right on the money.  I believe the WPF ControlTemplate model and DataTemplate model are an implementation of ViewModel itself.  I'm pretty sure the DataTemplate model came about as a result of the development of Blend.  Several of WPF's features were added on the recommendation of the Blend team.  However, the templating systems are not a very good implementation of the ViewModel pattern.  They leave much to be desired.  When I first started using the ViewModel pattern, we leveraged DataTemplates quite a bit.  Now, I only use them in the most trivial of scenarios.  I use Caliburn's View.Model attached property instead.  It basically gets me all the features of DataTemplates plus a few extras that are quite useful for VM style development.  Arguably, I could have developed this functionality as a DataTemplateSelector, but this extension point is not present in Silverlight, and I wanted a consistent mechanism for doing ViewModels across both platforms.  It also turns out that DataTemplates are not as easy to work with in Blend as UserControls.  In short though, I think WPF could have been much better had this style of development been *explicitly* architected into the framework from the beginning.

Skelly wrote re: MVVM Study Part 2 – “View of the Model” or “Model of the View” ?
on 09-15-2009 11:08 AM

Thanks for this post. I now have a better understanding of MVVM and compare to MVC. I've also see the ViewModel as being responsible for "modeling of the view" as opposed to "viewing of the model".

The question I have is what about input validation (ie; IDataErrorInfo in MVC) -- how would this work in an M-V-VM app?

.NET & Funky Fresh wrote MVVM Study - Interlude
on 05-01-2010 12:35 PM

There’s a whole lot of talk these days about MVVM. It’s the “hep” thing and everyone

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)