this question is going to show my lack of understanding of the expected behavior when implementing/using INotifyPropertyChanged:
The question is - for binding to work as expected, when you have a class which itself implements INotifyPropertyChanged, that has nested properties of type INotifyPropertyChanged are you expected to internally subscribe to change notification for these properties and then propagate the notifications? Or is the binding infrastructure expected to have the smarts to make this unnecessary?
For example (note this code is not complete - just meant to illustrate the question):
public class Address : INotifyPropertyChanged
{
string m_street
string m_city;
public string Street
{
get { return m_street; }
set
{
m_street = value;
NotifyPropertyChanged(new PropertyChangedEventArgs("Street"));
}
}
public string City
{
get { return m_city; }
set
{
m_city = value;
NotifyPropertyChanged(new PropertyChangedEventArgs("City"));
}
}
public class Person : INotifyPropertyChanged
{
Address m_address;
public Address
{
get { return m_address = value; }
set
{
m_address = value;
NotifyPropertyChanged(new PropertyChangedEventArgs("Address"));
}
}
}
So, in this example we've got a nested Address object in a Person object. Both of which implement INotifyPropertyChanged so that alteration of their properties will result in transmission of property change notifications to subscribers.
But let's say using binding someone is subscribing to change notification on a Person object, and is 'listening' for changes to the Address property. They will receive notifications if the Address property itself changes (a different Address object is assigned) but WILL NOT receive notifications if the data contained by the nested address object (the city, or street) are changed.
This leads to the question - is the binding infrastructure expected to handle this, or should I within my implementation of Person be subscribing to change notifications on the address object and then propagating them as changes to "Address"?
If you get to this point, thanks for just taking the time in reading this long winded question?
One of the simplest ways to do it is to add an event handler to Person which will handle notification events from m_address object:
public class Person : INotifyPropertyChanged
{
Address m_address;
public Address
{
get { return m_address = value; }
set
{
m_address = value;
NotifyPropertyChanged(new PropertyChangedEventArgs("Address"));
m_address.PropertyChanged += new PropertyChangedEventHandler( AddressPropertyChanged );
}
}
void AddressPropertyChanged( object sender, PropertyChangedEventArgs e )
{
NotifyPropertyChanged(new PropertyChangedEventArgs("Address"))
}
}
You answered this question when you said
...say using binding someone is subscribing to change notification on a Person object,
That someone is subscribing to Person and has no way to know if Address has changed. So you will have to handle this situation on your own (which is quite easy to implement).
If you want to child objects to see as if they are part of a their parent directly you need to do the bubbling yourself.
For your example, you would be binding to 'Address.Street' in your view, so you need to bubble a notifypropertychanged containing that string.
I wrote an easy helper to do this. You just call BubblePropertyChanged(x => x.BestFriend) in your parent view model constructor. n.b. there is an assumption you have a method called NotifyPropertyChanged in your parent, but you can adapt that to suit.
/// <summary>
/// Bubbles up property changed events from a child viewmodel that implements {INotifyPropertyChanged} to the parent keeping
/// the naming hierarchy in place.
/// This is useful for nested view models.
/// </summary>
/// <param name="property">Child property that is a viewmodel implementing INotifyPropertyChanged.</param>
/// <returns></returns>
public IDisposable BubblePropertyChanged(Expression<Func<INotifyPropertyChanged>> property)
{
// This step is relatively expensive but only called once during setup.
MemberExpression body = (MemberExpression)property.Body;
var prefix = body.Member.Name + ".";
INotifyPropertyChanged child = property.Compile().Invoke();
PropertyChangedEventHandler handler = (sender, e) =>
{
this.NotifyPropertyChanged(prefix + e.PropertyName);
};
child.PropertyChanged += handler;
return Disposable.Create(() => { child.PropertyChanged -= handler; });
}
An old question, nevertheless...
My original approach was to attach child property changed to the parent. This has an advantage, consuming the event of the parent is easy. Just need to subscribe to the parent.
public class NotifyChangedBase : INotifyPropertyChanged
{
public event PropertyChangedEventHandler PropertyChanged;
readonly Dictionary<string, AttachedNotifyHandler> attachedHandlers = new Dictionary<string, AttachedNotifyHandler>();
[NotifyPropertyChangedInvocator]
protected virtual void OnPropertyChanged([CallerMemberName] string propertyName = null)
{
PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
}
protected void AttachPropertyChanged(INotifyPropertyChanged notifyPropertyChanged,
[CallerMemberName] string propertyName = null)
{
if (propertyName == null) throw new ArgumentNullException(nameof(propertyName));
// ReSharper disable once ExplicitCallerInfoArgument
DetachCurrentPropertyChanged(propertyName);
if (notifyPropertyChanged != null)
{
attachedHandlers.Add(propertyName, new AttachedNotifyHandler(propertyName, this, notifyPropertyChanged));
}
}
protected void DetachCurrentPropertyChanged([CallerMemberName] string propertyName = null)
{
if (propertyName == null) throw new ArgumentNullException(nameof(propertyName));
AttachedNotifyHandler handler;
if (attachedHandlers.TryGetValue(propertyName, out handler))
{
handler.Dispose();
attachedHandlers.Remove(propertyName);
}
}
sealed class AttachedNotifyHandler : IDisposable
{
readonly string propertyName;
readonly NotifyChangedBase currentObject;
readonly INotifyPropertyChanged attachedObject;
public AttachedNotifyHandler(
[NotNull] string propertyName,
[NotNull] NotifyChangedBase currentObject,
[NotNull] INotifyPropertyChanged attachedObject)
{
if (propertyName == null) throw new ArgumentNullException(nameof(propertyName));
if (currentObject == null) throw new ArgumentNullException(nameof(currentObject));
if (attachedObject == null) throw new ArgumentNullException(nameof(attachedObject));
this.propertyName = propertyName;
this.currentObject = currentObject;
this.attachedObject = attachedObject;
attachedObject.PropertyChanged += TrackedObjectOnPropertyChanged;
}
public void Dispose()
{
attachedObject.PropertyChanged -= TrackedObjectOnPropertyChanged;
}
void TrackedObjectOnPropertyChanged(object sender, PropertyChangedEventArgs propertyChangedEventArgs)
{
currentObject.OnPropertyChanged(propertyName);
}
}
}
The usage is simple:
public class Foo : NotifyChangedBase
{
Bar bar;
public Bar Bar
{
get { return bar; }
set
{
if (Equals(value, bar)) return;
bar = value;
AttachPropertyChanged(bar);
OnPropertyChanged();
}
}
}
public class Bar : NotifyChangedBase
{
string prop;
public string Prop
{
get { return prop; }
set
{
if (value == prop) return;
prop = value;
OnPropertyChanged();
}
}
}
However, this approach is not very flexible and there is no control over it, at least without additional complex engineering. If the subscribing system has the flexibility to traverse nested data structures, it's applicability is limited to 1st level children.
While the caveats may be acceptable, depending on usage, I have since moved away from this approach, as it's never certain how the data structure is going to eventually be used. Currently preferring solutions such as this one:
https://github.com/buunguyen/notify
That way even complex data structures are simple and predictable, it is under subscriber control how to subscribe and how to react, it plays well with capabilities of binding engines.
来源：https://stackoverflow.com/questions/1336414/when-nesting-properties-that-implement-inotifypropertychanged-must-the-parent-ob