Comments on: Refactor Safe Implementation Of INotifyPropertyChanged

By: sean kearon

sean kearon — Thu, 03 Sep 2009 15:12:45 +0000

Hi Davy

Great article and a great approach to avoiding strings. The approach I take is to use AOP and let PostSharp do the work at compile time. Design time you have code that looks something like:

[NotifyChanges] public string Name { get; set }

Alternatively, you can take a convention approach and put an attribute on the assembly (using a property attribute to exclude properties that should not publish notifications). I have a couple of posts linked below that illustrate the approach and there is more on the PostSharp website.

Cheers

Sean

http://kearon.blogspot.com/2008/10/using-c-automatic-properties-with-xpo_27.html
http://kearon.blogspot.com/2008/10/using-c-automatic-properties-with-xpo.html

By: Nima

Nima — Sat, 29 Aug 2009 05:47:42 +0000

OK I get it. It seems that if an UnaryExpression is given we should use its Operand to get its MemberExpression.
var memberExpression =(expression.Body is UnaryExpression? expression.Body.Operand :expression.Body) as MemberExpression;

By: Nima

Nima — Sat, 29 Aug 2009 05:34:00 +0000

Thanks for your post!
I think that I’m doing something wrong.As long as I pass a non struct property ( a string property for example) everything is fine but when I try to pass a struct property (an integer or a boolean) It won’t get a MemberExpression but some other type of expression (UnaryExpression for example)

By: Davy Brion

Davy Brion — Tue, 18 Aug 2009 18:43:42 +0000

there was only a performance penalty noticeable after triggering the event a couple of thousands times. obviously, if you’re doing that you’ve probably got bigger problems to worry about than the performance overhead of using an expression instead of a string

By: Brian

Brian — Tue, 18 Aug 2009 18:38:38 +0000

Interesting idea, I’m still trying to digest it.

What kind of overhead does this create? Performance or dependencies?

Right now, I’m just unit testing to verify the PropertyChanged event is thrown with the correct property name. (Very similiar to your AssertThatPropertyChangedIsCorrect)

By: Davy Brion

Davy Brion — Fri, 07 Aug 2009 04:46:04 +0000

passing the propertyname as a string was exactly what we were trying to get away from
it’s actually less typing now because of the intellisense support.

By: Frederik

Frederik — Thu, 06 Aug 2009 23:27:06 +0000

Although I fully understand the advantage of this (I also hate hardcoded strings in my code, and I’ve annoyed myself over this INotifyPropertyChanged implementation as well), I still think that this is some kind of cumbersome solution.
I think that the code becomes less readable.

For the moment, I do it like this:
In my base class which implements INotifyPropertyChanged, I also have a method called ‘PropertyChanged’, which looks like a bit like this (from the top of my head):

protected void PropertyChanged( string propertyName ) { if( String.IsNullOrEmpty (propertyName) ) { throw new ArgumentNullException (propertyName); }


    #if DEBUG
    if( !PropertyExists (propertyName) )

    {

         throw new ArgumentException ("No such property", propertyName);

    }
    #endif

PropertyChanged (this, new PropertyChangedEventArgs(propertyName)); }

The PropertyExists method uses reflection in order to check whether the class has a property with the given name. (But I’m sure you’ve guessed this already ).