7

I am starting to learn LINQ-to-SQL for Windows Phone 8, and came across this article on MSDN.

They show a base class for DataContext which implements both INotifyPropertyChanging and INotifyPropertyChanged. The reasoning for the INotifyPropertyChanging is:

◦The INotifyPropertyChanged interface is used for change tracking.

◦The INotifyPropertyChanging interface helps limit memory consumption related to change tracking.

The article fails to give any specific references to justify the claim of memory consumption to the INotifyPropertyChanging interface. The article on INotifyPropertyChanging itself just says:

Notifies clients that a property value is changing.

Can someone please explain to me how this interface which limits the memory footprint of an application, just by notifying that a property value is about to change (and not even restricting that change to from happening)?

Adarsha
  • 2,267
  • 22
  • 29
  • 1
    Perhaps your opinion would be heard [here](http://visualstudio.uservoice.com). – Scott Solmer Sep 02 '14 at 15:42
  • Agreed, that's a pretty content-poor API documentation page. I'm not familiar with that interface, but I've recently raised a question about bound dependency properties and thought you might have stumbled across a potential answer. – Evil Dog Pie Sep 02 '14 at 15:44
  • It does not make much sense. When you don't use the `INotifyPropertyChanged` the .NET [uses the much more heavy](http://stackoverflow.com/questions/19784028/propertydescriptor-and-wpf-binding-mechinsm) `PropertyDescriptor` to track changes. But as far as I know it aplly for the one I mentioned not the `INotifyPropertyChanging` so not sure why they wrote this. – Vitor Canova Sep 02 '14 at 16:05
  • @Okuma.Scott Infact I started one for the WPDev User voice, http://wpdev.uservoice.com/forums/110707-docs/suggestions/2525647-better-msdn-documentation-like-we-have-for-win32-a – Adarsha Sep 02 '14 at 16:06
  • It is subjective, but guessable. By pushing the burden on the client code to detect changes, the framework doesn't have to keep the old data around anymore and detect the changes itself. Sure, that makes it use less memory. And makes data binding a lot more efficient. There however is no INotifyPropertyChangeReverted so it isn't like it is a total cakewalk. – Hans Passant Sep 02 '14 at 16:17
  • If you have to implement either of those interfaces, you need to keep track of the old value to know when to raise the events. As a consumer, you just listen to the event, and get the current value of the property. I have not come across a consumer which tracks the old and new values. – Adarsha Sep 02 '14 at 16:45

2 Answers2

4

I can only extrapolate, but I think that's what the author had in mind:

In a world without INotifyPropertyChanging, if the consumer needs the old value of a property, it has to preemptively cache it (because, once the PropertyChanged event is raised, it's too late and the value is already changed). Alternatively, the producer can keep a copy of the old value in distinct properties. Either way, the data remains duplicated all the time.

With INotifyPropertyChanging, the consumer doesn't need to cache anything beforehand. When the PropertyChanging event is raised, it can grab the old value, knowing it's about to change. Then the NotifyPropertyChanged event is raised, the consumer can grab the new value, do whatever with both, then drop them. The data is still duplicated, but only at a certain point of time and for a limited duration.

Kevin Gosse
  • 38,392
  • 3
  • 78
  • 94
  • I take this as an answer as the original article said "Helps limit" and did not say it actually limits the memory footprint. But do you know of any controls which bind to these interfaces, actually differing in behavior depending on the presence of INotifyPropertyChanging ? – Adarsha Sep 03 '14 at 06:55
  • 1
    @Adarsha I don't. And if I were to develop a control, I probably wouldn't support INotifyPropertyChanging, knowing that it's only scarcely implemented – Kevin Gosse Sep 03 '14 at 07:42
2

Okay, I finally found another MSDN article which actually explains how INotifyPropertyChanging will limit memory footprint. Quoting the article (emphasis mine):

Notifications are provided through the PropertyChanging event in property setters. When LINQ to SQL is notified of the first change to an object, it creates a copy of the object and considers the object a candidate for generating an Update statement.

For objects that do not implement INotifyPropertyChanging, LINQ to SQL maintains a copy of the values that objects had when they were first materialized.

So if you don't implement INotifyPropertyChanging and never update any objects fetched using Linq-SQL, it will still create a copy of the object for every object it creates. By implementing the interface, you can avoid that additional memory usage, and have it create copies only when you actually are making a change to the object state.

Adarsha
  • 2,267
  • 22
  • 29