获取PropertyInfo名称和值

Question

I have seen various ways of doing this including reflection, component model type descriptors, expression trees, and aspects, BUT I'm still not sure whether the code below achieves all of the following objectives using .Net 4.0 or higher:

1. Be type safe, refactor friendly (no magic strings), and readable
2. Maximize performance over multiple calls
3. Provide the name of a property
4. Provide the value of the property

How can the code be improved?

protected void NotifyOfPropertyChanging<TProperty>(Expression<Func<TProperty>> property) {
    var memberExpression = (MemberExpression)property.Body;
    var prop = (PropertyInfo) memberExpression.Member;

    var propertyName = prop.Name;
    var value = prop.GetValue(this, null);

    // fire INPC using propertyName
    // use value and name to do IsDirty checking
}

Answer 1

You might be able to improve performance by compiling the expression tree and caching it for future use rather than calling GetValue every time. However such optimizations should only be made if your current implementation causes a bottleneck.

void NotifyOfPropertyChanging<TProperty>(Expression<Func<TProperty>> property)
{
    var memberExpression = (MemberExpression) property.Body;
    var prop = (PropertyInfo) memberExpression.Member;

    Func<TProperty> accessor;
    if (!TypedAccessorCache<TProperty>.Cache.TryGetValue(prop, out accessor))
    {
        accessor = property.Compile();
        TypedAccessorCache<TProperty>.Cache[prop] = accessor;
    }
    var value = accessor();

    // ...
}

static class TypedAccessorCache<TProperty>
{
    public static readonly IDictionary<PropertyInfo, Func<TProperty>> Cache =
        new Dictionary<PropertyInfo, Func<TProperty>>();
}

Notice I've used a generic static type to hold the cache dictionary instance. This is a handy way to effectively create a separate typed cache for each distinct property type.

Answer 2

It's a long story and I guess there is still no single approach that is better than others. I think that expressions will not make a performance bottle-neck in most usual business scenarios (and you can optimize a small piece of code that need faster notifications later if you ever need it), so this approach should be fine.

Just keep in mind that creating expression tree is much more time-consuming that parsing it, so make sure that you do this only once (ie by using static class-level expression variables). However, your model code becomes a bit bloated in that case.

I personally prefer using string-based INPC handling. ReSharper works fine with strings when it comes to refactoring, so I can call it relatively safe. As far as I know, this is the fastest approach. And using VS or ReSharper snippets, you can easily write your properties in several keystrokes.

Regarding the property value - it is not used neither by INotifyPropertyChanging nor by INotifyPropertyChanged interface. Why do you need it?