One slight problem I had, was that the attribute currently does not seem to work when you also have pure getters in your class. To fix that, I added

return if property.Setter is null

to the beginning of “AddNewBody”.

It is no problem to add additional logic in the getters and setters. What the NotifyPropertyChanged-attribute does is to add, at the end of each setter, the event notification. In the AddNewBody-method I first add the $OldBody to the new body, then add the event notification.

The PropertyChanged is available from your code since it is added compile time before your logic is resolved. You will not find it through intellisense, but this is more a tools-issue. In addition I will not recommend coding directly against the autogenerated (at compile time) PropertyChanged event. It will couple you too much to the attributes interal workings. That being said, I should probably have given the event a guarantied unique name (which you can easily do) so there won’t be any confusion.

Would it be possible to add additional logic to some of the setters/getters of the properties, and still get the event notification?

Or – say you want to add a third property, like e-mail, where you want to do validation logic in the setter?

I guess what I’m asking: In class BooCustomer, is the PropertyChanged event available implicitly because of the NotifyPropertyChanged attribute?