Change Notification In Linq To SQL

If you have generated your Linq to SQL classes using visual studio Designer or used sqlmetal utility, you would notice that your entity classes implement two very important interfaces for change tracking called INotifyPropertyChanging and INotifyPropertyChanged interface. These interfaces belong to System.ComponentModel namespace and were introduced in .net 3.0 runtime. Although the use of these interfaces are not mandatory for your entity classes but having them make the change tracking process efficient and less memory intensive. If your entities do not implement Notification interfaces, Linq to SQL will keep track of two copies of your objects, one with the original values when you first fetched the object and second object which has changes applied to it. When submit changes is called, Linq to SQL will do a compare of those objects and send only the properties which has changed since the first retrieval. This process which keeps tracks of two copies of the object can cause memory issues when you are managing lots of objects. Therefore Linq to SQL also provides an option where it can allow entities to to participate in change tracking service. Entities can participate in change tracking service by implementing INotifyPropertyChanging interface and INotifyPropertyChanged interface and raise propertychanging and property changed event in the setter of the property. Let's look at some code below to see how our entities can participate change notification service.

In the above screen shot, I have limited my code to demonstrate how entities classes participate in change notification service when a particular property gets changed to when something gets removed or added to the collection. When we implement INotifiychanging and changed interface we automatically get two events called Propertychanging and PropertyChanged. The first time you request the object from the database, Linq to SQL checks to see if the object implements INotifiychanging and Changed. If it implements the interface than it registers with the two events in our Customer class. If our entity does not implement the interface, it create a copy of the object to be used later to compare it with the modified object. In my customer entity I have Name property. Every time Name property changes, in the setter of the Name property, I am raising Propertychanging followed by PropertyChanged passing the Name of the property that got changed. This notifies Linq to SQL that a property has changed.

For notifying when collection gets modified, in the constructor of the customer entity, I am creating an instance of orders entityset. Order entity set has constructor that takes two action delegates. Firsts action delegate gets called when an Order gets added to the orders collection. Second delegate gets called when an order gets removed from the order collection. I am representing both the delegates as simple lambda expressions that basically raises a changing and changed event to notify Linq to SQL that order collection has changed. In a more real world code, you probably want to do lot more stuff inside the add and remove action delegate.