this.RaisePropertyChanged( () => this.Name);

you can write:

this.RaisePropertyChanged( () => this.Name);

Regards

Very nice work indeed. Though due to delegate inference you can eliminate the need for expressing the generic parameter type without extension methods. For example instead of writing:

this.RaisePropertyChanged( () => this.Name);

you can write:

this.RaisePropertyChanged( () => this.Name);

Regards

Yes. I did it. Please take a look at my comments from this post. There are two of my comments that I mentioned about the comparison.

Did you ever run any test showing the performance impact on using the expression tree rather then just passing in the string name?

>>If performance is a key issue then Expression Tree based solution in this context will have some performance penalties as reflection is involved during the decoding of expressions

I think reflection and Expression Tree are different things. I’m not sure whether there are some performance penalties on using Expression Tree. Anyway, you brought good point. I will dottrace the performance..

We can use [NotifyPropertyChanged] attribute with PostSharp or Interception. But I personally don’t like PostSharp that much since it makes my VS very slow.

Interception (e.g. Unity Interception) might be good too but I haven’t tried it yet. I found some samples that are using Unity Interception for that purpose..

Good approach. You get rid off of passing hard coded string as property name which is good for producing clean code and killing the chance of mistyping the property name when raising the PropertyChanged event.

Only one concern, If performance is a key issue then Expression Tree based solution in this context will have some performance penalties as reflection is involved during the decoding of expressions. And that PropertyChanged event will get called countless times during your application life cycle. In this scenario you get best possible performance by passing hard coded string as property name. But off course that hard coding doesn’t look cool and can be error prone.

For now I only see one better solution that avoids both reflection at runtime and hard coded property name in your code as well; and that is by using postsharp aspect to auto implement INotifyPropertyChanged interface in any classes. You also get rid off code to manually raise the event in your classes. Your code will look like this

/* aspect that auto implements INotifyPropertyChanged. You need to create it by overriding existing post sharp aspect */

[NotifyPropertyChanged]
public class Person
{
public string Name{ get; set; }
public int Age { get; set; }
}

Looks much cleaner right ?

The attribute/custom aspect will auto implement INotifyPropertyChanged for every single property you have and works excellent with WPF data binding without adding any extra performance overhead.

In case you are interested about listening to that propertychanged event from other classes you can do it like that….

INotifyPropertyChanged P = Person as INotifyPropertyChanged;
P.PropertyChanged += (sender, arg) => { /* Your Event handling code goes here */ };

- Roko