Introduction

Getting data from the database to the UI is a snap with LINQ to SQL. Getting the changes made to your entities is a little more difficult.

Please note: This article assumes knowledge of LINQ to SQL and C#. If you are new to LINQ, I recommend you to read the following article.

For this example, I have run the SqlMetal utility against the Northwind database. I feel it is better to start with the results, and then discuss the steps to get there.

The Results

Output:

The Implementation - Where the magic happens

To get the list of changed items, I needed to create an extension method that used reflection. I made the decision to use generics simply for the added benefit of strong typing.

The GetChangedItems method first interrogates the DataContext instance for its private member called services It then queries for services private member tracker, followed by a query for the tracker's private member items. Whenever an object has changed, the DataContext attaches a reference of the current and original objects to the items, which is of type IDictionary. The method loops through this dictionary, adding each item of the type specified to our list.

You may have noticed the ChangedItems class in the above code. This class is a container that identifies the Current and Original objects.

Future Enhancements - Implementing Business Logic and Server-Side Validation

Now that we have implemented a mechanism for detecting changes, we can easily implement the business logic and validation. Since the classes generated by SqlMetal are partial classes, we can easily extend them. We would first need to create an interface called IBusinessObject via the Validate() method that returns an List<string> object. Second, we could extend our Customer class to implement the IBusinessObject interface, and fill out the logic for the Validate() method. Third, we can call our GetChangedItems method, pass an IBusinessObject for our type to search for, and loop through the results calling the Validate() method on each to get a list of validation errors.

Now suppose we wanted to go a little bit further and enforce that each changed IBusinessObject was persisted ONLY if the validation passed. We could override the DataContext.SubmitChanges method, calling GetChangedItems<IBusinessObject>(), invoking Validate() on each IBusinessObject in the list adding the results to a list of validation errors. If there aren't any errors in the list, we can call the base.SubmitChanges.

Summary

In short, there is a lot of functionality in the .NET Framework, much of which is abstracted for us. This article serves as an example in which extension methods can be used to tap into the functionality when needed.

About Ryan Haney

Sorry, no bio is available View complete profile here.