How can we implement change notification propagation for WPF and SL in the MVVM pattern?
Posted
by
Firoso
on Stack Overflow
See other posts from Stack Overflow
or by Firoso
Published on 2010-12-30T23:58:45Z
Indexed on
2010/12/31
1:54 UTC
Read the original article
Hit count: 535
Here's an example scenario targetting MVVM WPF/SL development:
- View data binds to view model Property "Target"
- "Target" exposes a field of an object called "data" that exists in the local application model, called "Original"
- when "Original" changes, it should raise notification to the view model and then propogate that change notification to the View.
Here are the solutions I've come up with, but I don't like any of them all that much. I'm looking for other ideas, by the time we come up with something rock solid I'm certain Microsoft will have released .NET 5 with WPF/SL extensions for better tools for MVVM development.
For now the question is, "What have you done to solve this problem and how has it worked out for you?"
Option 1.
Proposal:
Attach a handler to data's PropertyChanged event that watches for string values of properties it cares about that might have changed, and raises the appropriate notification.
Why I don't like it:
Changes don't bubble naturally, objects must be explicitly watched, if data changes to a new source, events must be un-registered/registered.
Why I kind of like it:
I get explicit control over propogation of changes, and I don't have to use any types that belong at a higher level of the application such as dependancy properties.
Option 2.
Proposal:
Attach a handler to data's PropertyChanged event that re-raises the event across all properties using the name property name.
Why I don't like it:
This is essentially the same as option 1, but less intelligent, and forces me to never change my property names, as they have to be the same as the property names on data
Why I kind of like it:
It's very easy to set up and I don't have to think about it... Then again if I try to think, and change names to things that make sense, I shoot myself in the foot, and then I have to think about it!
Option 3.
Proposal:
Inherit my view model from dependancy object, and notify binding sources of changes directly.
Why I don't like it:
I'm not even 100% sure dependancy properties/objects can DO this, it was just a thought to look into. Also I don't personally feel that WPF/SL types like Dep Obj belong at the view model level.
Why I kind of like it:
IF it has the capability that I'm seeking then it's a good answer! minus that pesky layering issue.
Option 4.
Proposal:
Use a consistant agent messaging system based off of Task Parallels DataFlow Library to propogate everything through linked pipelining.
Why I don't like it:
I've never tried this, and somehow I think it will be lacking, plus it requires me to think about my code completely differently all the way around.
Why I kind of like it:
It has the possiblity of allowing me to do some VERY fun manipulations with a push based data model and using ActionBlocks as validation AND setters to then privately change view model properties and explicitly control PropertyChanged notifications.
© Stack Overflow or respective owner