views:

126

answers:

4

Sorry if this has already been asked, but I just want to make sure that I'm doing this right.

If I have a domian object that has say 10 properties on it. I have a grid on my main form that I want to show the pretty much all the the properties from the model.

I created a viewmodel to wrap the domain object to show in the gridview but then I have to expose all the properties again. I just feel binding straight against the model through the viewmodel feels dirty and defects the purpose a bit.

So for example I don't really like this:

 {Binding DomainObject.Property}

where DomainObject is property on my view model.

So my main question is, should I expose all the properties on the model through the view model just to bind it to the grid?

EDIT: Just for added information the domian objects are LINQ-To-SQL objects, so I don't think they implement INotifyPropertyChanged but I'm not sure.

+1  A: 

If you need change notification on the properties and the model doesn't implement INotifyPropertyChanged, then you need to create new properties on the ViewModel. Otherwise, it's probably not a big issue to bind directly to the model : the MVVM pattern is just a guideline, you can bend the rules a little if necessary...

Thomas Levesque
A: 

I think it is a matter of personal preference. I happen to believe it is perfectly fine to expose the Model in a single object from the ViewModel. Recreating all the properties of the Model in the ViewModel just results in a bunch of extra code.

However, this only works provided your Model implements change notifications so the data binding works.

John Myczek
+3  A: 

Some people will say it doesn't matter, others say it does. I'm in the latter camp, for these reasons:

  • You increase the dependencies of the view, as it now depends on the data model, not just the view model.
  • You require the designers need to know the properties and structure of your data model.
  • You create more work for the (almost inevitable) refactoring when you decide you need a layer of indirection for formatting, validation, or whatever it might be.
  • As Thomas pointed out, data models often don't implement change notification

Yes, it's a little more work, but I believe it's worth it to reduce decoupling, maintenance headaches, collaboration with designers, and correctness.

HTH, Kent

PS. If you find yourself in this situation a lot, you might consider an implementation of ICustomTypeDescriptor that wraps any data object and exposes its properties with change notification. That way your VM can extend this generic wrapper until you decide you need to pull properties out for purposes such as formatting and validation.

Kent Boogaart
The formatting and validataion was something that I was thinking about that would cause problems.
Nathan W
The program I am writing is only fairly small so I don't think I will go with the ICustomTypeDescriptor way, but good to know.
Nathan W
I've suggested to a fellow college to implement ICustomTypeDescriptor in order to solve the same type of MVVM dilemma. I think this would be a good starting point for those who want a strict separation of their View from their Model but have a complex system to implement which would require writing to many transmogrifiers.
jpierson
+1  A: 

Phil Haack has a pretty good post on this:

http://haacked.com/archive/2009/07/14/law-of-demeter-dot-counting.aspx

blu
I wasn't really worried about the law of demeter for this, more the stuff that Kent has addressed. The decoupling it creates between the model and view via the viewmodel.
Nathan W