Should ViewModel have pass-through DependencyProperties that bind to DependencyProperties on the Model?

Question

I am new to WPF/MVVM and the examples I have found do not seem to cover an issue I am facing.

I have a screen for managing a rather complex business configuration object. In MVVM I think this means I should have the following:

1. A XAML View with close to zero logic
2. A ViewModel class that has the screen logic
3. My usual business classes fill the role of Model and have all business logic

In my situation there are business rules that say changes to fieldA of my business class might have various side effects, for example changing the value of fieldB, or populating an entire list of sub-objects.

I could be wrong, but I think I should keep these rules encapsulated in the business class, as these rules are not really about the screen so much as the entity.

Naturally, these side-effects need to make their way back onto the screen immediately.

So from the user's perspective, he might edit fieldA, and see fieldB updated on the View.

I understand how to databind from the View to the ViewModel.

But in my case, it seems that I need two layers of databinding: one between the View and ViewModel, and another between the ViewModel and the Model.

Given that I have essentially the same problem twice, I think one solution should apply. So I have made my Model class into a DependencyObject, and I have made its properties into DependencyProperties.

Looking at fieldA for example, it would appear in all three layers:

1. View as a visual component databound to ViewModel.FieldA, for example text="{Binding FieldA, Mode=TwoWay}"
2. ViewModel as a DependencyProperty bound "upward" to the View, and "downward" to the Model
3. Model as a DependencyProperty

I prefer not to directly couple my View XAML to the business object by skipping part #2, this does not seem like a clean application of the pattern to me. Perhaps that is misguided.

I essentially seem to need a "pass-through DependencyProperty" in my ViewModel.

My questions:

• Is this the right general approach or am I thinking about it all wrong?
• Are there examples out there using this pass-through approach?
• Can someone give a code example of the proper way to create a pass-through binding between the ViewModel and Model FieldA DependencyProperties?

Answer 1

I struggled with this issue myself, and I imagine it is a very common snag when it comes to MVVM. My answer was to avoid polluting the domain with DependencyObject or INotifyPropertyChanged as it somewhat negates the validity of using a ViewModel.

The goal of a ViewModel is to expose a model in a manner that is relevant to a particular view. It gets confusing when the VM essentially needs to expose an entire domain object. I refer to these as "Editor" view models. These are the most tempting to pass through properties from the domain object. In these cases I give the VM a reference to a domain object (composition) and pass through getters and setters. The ViewModel adopts INotifyPropertyChanged and IDataErrorInfo rather than DependencyProperty to signal the UI if the UI needs to refresh or display validation errors. If the domain raises a validation error, then the VM catches it and prepares it into the data error info details for the view.