Don't forget one thing : PropertyChanged
event is mainly consumed by components that will use reflection to get the value of the named property.
The most obvious example is databinding.
When you fire PropertyChanged
event, passing the name of the property as a parameter, you should know that the subscriber of this event is likely to use reflection by calling, for instance, GetProperty
(at least the first time if it uses a cache of PropertyInfo
), then GetValue
. This last call is a dynamic invocation (MethodInfo.Invoke) of the property getter method, which costs more than the GetProperty
which only queries meta data. (Note that data binding relies on the whole TypeDescriptor thing -- but the default implementation uses reflection.)
So, of course using hard code property names when firing PropertyChanged is more efficient than using reflection for dynamically getting the name of the property, but IMHO, it is important to balance your thoughts. In some cases, the performance overhead is not that critical, and you could benefit from some kind on strongly typed event firing mechanism.
Here is what I use sometimes in C# 3.0, when performances would not be a concern :
public class Person : INotifyPropertyChanged
{
private string name;
public string Name
{
get { return this.name; }
set
{
this.name = value;
FirePropertyChanged(p => p.Name);
}
}
private void FirePropertyChanged<TValue>(Expression<Func<Person, TValue>> propertySelector)
{
if (PropertyChanged == null)
return;
var memberExpression = propertySelector.Body as MemberExpression;
if (memberExpression == null)
return;
PropertyChanged(this, new PropertyChangedEventArgs(memberExpression.Member.Name));
}
public event PropertyChangedEventHandler PropertyChanged;
}
Notice the use of the expression tree to get the name of the property, and the use of the lambda expression as an Expression
:
FirePropertyChanged(p => p.Name);
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…