This project is read-only.


Nov 25, 2009 at 5:11 PM

I'm curious if you could quantify the improvements that are achieved when DoesEntireTreeSupportINotifyPropertyChanging is true.

Also, what would the impact of a false positive be as in 

string property { get {} set { NotifyChanging("property"); if(value == "bad") return; _property = value; NotifyChanged("property"); }

I ask because I'm using LLBLGen as my OR/M and it does a lot of validation of properties.  It also support rolling back individual properties.  Adding Changing support seems to be a bit outside feasibility, so I wanted to know what I'm missing out on.


Dec 15, 2009 at 2:45 PM

Sorry for the late reply, I was on vacation, and I don't get notification when people post to the forum. 

In a nutshell, CLINQ must subscribe to a tree of objects in order to do it's magic.  For example:

var peopleWithBrothersOver20 = from person in people where person.Brother.Age > 20 select person

For each person in the people collection, I need subscribe to that person's PropertyChanged event.  I'm also looking at each person's brother property, and the age of that person's brother.  When any of these properties change, I need to reevaluate the filter to determine if the output of the collection needs to be updated.  So this means that I need subscribe to person.PropertyChanged, person.Brother.PropertyChanged.  Now that's easy enough to do.  However, let's say the person.Brother gets replaced with a new object.  I need to unsubscribe from the old person.Brother.PropertyChanged.  INotifyPropertyChanging tells me the property is changing, so I can examine the value of person.Brother before it changes, and so it's easy enough to unsubscribe from person.Brother because the value of the property has not been updated to the new value yet. 

Now, without INotifyPropertyChanging, I still have to unsubscribe from the old person.Brother.  How to do that?  Well, I need to basically keep a copy of the object tree for each object in each query.  This requires a ton of memory, and of course increases heap fragmentation, cache mises, etc.  The apps I work that utilize CLINQ have over 100 queries and in some cases monitor collections of 3.5 million objects.  The INotifyPropertyChanging optimization becomes very important, as now a subscription only stores two or three references to other objects and a couple entries in a hashtable. 

Also, if you are using ReactiveObject, which also a corner stone (not enough people use it btw.) In one of our apps, we have over 1000 reactive definitions. The monitoring of those properties also benefits from this optimization.

I hope this answers your questions, and please do not hesitate to ask more questions.



Dec 15, 2009 at 4:46 PM

The object I'm wanting to monitor is an Entity generated by LLBLGen Pro.  I'd contacted them asking about the feasibility of implementing INotifyPropertyChanging.  The two questions were "What good is it?" (which you've answered nicely) and "What about validation in setters?"  In this case, there are a number of opportunities for the set to be cancelled.  What happens if I notify changing, but never change?

Our discussion is here (not sure if this is publicly available or if you need a login):

FWIW, I use RSS to monitor these discussions.