Analog DependencyProperty for the WPF MVVM Model

Question

I have MVVM, and the model consists of a number of related classes, but for the sake of this question we will focus on only four.

GrandParentModel, ParentModel, ChildModel, and Contact.

They all inherit from ModelBase, which has an implementation of INotifyPropertyChanged on it.

Thus, each of the three models has the Contact property. If the child does not have a property, he should look at the parent, and if the parent is empty, he will look at GrandParent. If the contact changes at the grandparents level, I would like for any dependents, that is, any child parents and their children, to raise a PropertyChanged event for their contact.

I think that everything that I am going to do will be supported by DependencyProperty, but I do not want to use this, since this is my model, separation of problems and all that. Therefore, I am building a mini-implementation, and everything is in order.

My question is: has anyone been on this path before, and is there anything I should worry about in the future? My Spidey-Senses are tingling, and I don't know why.

Thanks Ian

Edit: The relationship between the objects here is that grandparents have any number of parents and any number of children. My current model has a property for everyone that points to a parent (null in the case of grandfather), and parent / grandfather and grandmother have a set of child objects.

Answer 1

I was on this path, and this is not very. Basically you need to subscribe to the PropertyChanged ParentModel event from your ChildModel . You must take care of whether your child can change parents. Then, when you receive a notification of a change in the parent from a child's perspective, you should raise your own PropertyChanged event for the child. This gets ugly because you can end up with hanging event handlers that you forgot to clear.

The best way would be to create your own analogue for a model with DependencyProperty . Basically, in your ChildModel constructor ChildModel you “declare” that the Contact property delegates the Contact property of the Parent object when null. You do this with a small helper class that observes the ParentModel PropertyChanged event and, if necessary, ParentModel PropertyChanged event for the child. Also note that the Parent property will change on the child.

You can use the MVVM Light message bus. Grandfather and grandfather and parents send a message when their Contact property changes. Have your child listen to these messages. When he receives the message, check that it matches his own parent or grandparent, and raise the PropertyChanged event if necessary. This is better than any of the above methods, because you do not need to track the changes of your parent or grandfather. You are less likely to have errors. It also uses weak references, so it won’t hold objects like event handlers do.

Now what I'm doing is moving away from implementing my INotifyPropertyChanged model objects. I introduced a Presenter layer between my model and my ViewModel. Presenter actually creates the ViewModel from a small ViewModel widget (for example, one widget may be a ChangeValue<T> widget). I have a rule engine that tells Presenter how to compose a ViewModel from widgets for a given model. Presenter processes all of the user's input data (mostly lambda runs against the model), but since he knows that the user’s action just took place, he knows that something in the Model could change. After the model action is completed, it copies all the data from the model into the ViewModel. ViewModel checks the incoming data and raises the PropertyChanged event if the field has really changed. Obviously, the most compliant way to do this, but it gives you a really clean model, and neither ViewModel nor Presenter contain model logic (domain / business).