Unfortunately, after having a closer look at LINQ, I found that using LINQ in a multi-tier application can be quite a struggle. This article shows the typical pitfalls of implementing the data layer with LINQ to SQL and provides an simple, convenient and flexible way to circumvent most of them.

The generic base class for a LINQ-to-SQL Database Abstraction Layers (DAL) that comes with this article has the following features:

• Implements the Repository pattern, allowing you to conveniently implement CRUD (Create, Update, Delete) operations with less than ten lines of code per LINQ entity type.
• Works seamlessly in disconnected LINQ mode
• Supports transparent database updates of LINQ entity hierarchies in one single database roundtrip.
• As a convenience feature, it also writes all executed SQL statements to the output console when debugging your application.

I’m going to assume that you have a basic understanding of what LINQ to SQL (also known as DLINQ) does and how it is used. If you don’t, have a look at this tutorial first and come back to this page to see how to use LINQ to SQL in multi-tier applications.

The Problem

LINQ to SQL is incredibly easy to use if you simply hook your UI layer directly to the database with LinqToDataSource objects. But that’s not very object-oriented, and certainly not an advisable architecture unless you are coding a quick and dirty application and do not plan on extending it in the long run.

Instead, most developers divide their applications into several layers, for example the following:

• Data Access Layer
• Business Layer
• UI Layer

This is known as a multi-tier database application design. LINQ to SQL would be used in the Data Access Layer.

The problem with LINQ to SQL is that – despite it’s many advantages – it’s not very simple to use when implementing the data layer.

Have a look at the following database schema:

As long as you are loading and saving LINQ entities to the same data context instance (this is known as “connected mode”), implementing your Data layer with LINQ is very straightforward.

For example, let’s fetch the customer entity with ID==1 from the database, change its first name to “Homer” and save it back to the database. In an multi-tier database application the code might be somewhere in the UI or business layer and look like this:

//create a new repository instance
CustomersRepository customersRepository = new CustomersRepository();
//load a customer instance and change it's FirstName;
Customer customer = customersRepository.Load(2);
customer.FirstName = "Homer";
//commmit customer to database
customersRepository.Save(customer);

The easiest way to implement the data layer Load and Save functions used above is this:

static DataClassesDataContext context=new DataClassesDataContext();
public Customer Load(int CustomerID)
{
return context.Customers.Single(c => c.ID == CustomerID);
}
public void Save(Customer toSave)
{
context.SubmitChanges();
}

This approach is using connected LINQ mode: The data context never goes out of scope, so it can always be reused to save entities to the database which are still connected to it.

Granted, it is convenient and works for the isolated example above, but it has severe concurrency issues because one database context is used for all database operations:
When calling Save(), SubmitChanges commits ALL changed entities, not only those related to the LINQ entity that the Save Method received in the toSave parameter.

But even setting this flaw aside, you can’t implement the data layer in the same manner when using LINQ in a multi-tier ASP.NET application. Here, chances are that your LINQ entity is loaded with the one page request, then updated and saved to the database with the next page request. Meanwhile, your original data context has gone out of scope, making your LINQ entity disconnected.

And there are also many other scenarios where you need to use disconnected LINQ mode: For example you might want to implement your Database Layer as a web service, commit previously serialized LINQ entities to your database, etc.

Implementing the data layer with disconnected LINQ to SQL

So, how do we implement a Data layer Save() method that works in disconnected LINQ mode?

We have to

• Detach the entity from the old data context
• Create a new data context
• Attach the entity to the new context
• Submit changes

In source code, it looks like this:

public Customer Load(int CustomerID)
{
DataClassesDataContext context = new DataClassesDataContext();
return context.Customers.Single(c => c.ID == CustomerID);
}

public void Save(Customer toSave)
{
//the old data context is no more, we need to create a new one
DataClassesDataContext context = new DataClassesDataContext();
//serialize and deserialize the entity to detach it from the
//old data context. This is not part of .NET, I am calling
//my own code here
toSave = EntityDetacher<Customer>.Detach(toSave);
//is the entity new or just updated?
//ID is the customer table's identity column, so new entities should
//have an ID == 0
if (toSave.ID == 0)
{
//insert entity into Customers table
context.Customers.InsertOnSubmit(toSave);
}
else
{
//attach entity to Customers table and mark it as "changed"
context.Customers.Attach(toSave, true);
}
}

Now you can load and alter as many entities as you like and only commit some of them to the database. But due to using disconnected LINQ, this implementation does not account for associations between LINQ entities.

For example, imagine you want to do the following in your business or UI layer:

//load currently selected customer from database
Customer customer = new CustomersRepository().Load(1);
//change the customer's first name
customer.FirstName = "Homer";
//add a new bill with two billingitems to the customer
Bill newbill = new Bill
{
Date = DateTime.Now,
BillingItems =
{
new BillingItem(){ItemPrice=10, NumItems=2},
new BillingItem(){ItemPrice=15, NumItems=1}
}
};
customer.Bills.Add(newbill);
//create a new provider to simulate new ASP.NET page request
//save the customer
new CustomersRepository().Save(customer);

The disconnected mode Save() method above would commit the change to the FirstName column, but simply forget about the new bill and billing items. In order to make it work, we also need to recursively Attach or Insert all associated child entities:

public void Save(Customer toSave)
{
//the old data context is no more, we need to create a new one
DataClassesDataContext context = new DataClassesDataContext();
//serialize and deserialize the entity to detach it from the
//old data context. This is not part of .NET, I am calling
//my own code here
toSave = EntityDetacher.Detach(toSave);
//is the entity new or just updated?
//ID is the customer table's identity column, so new entities should
//have an ID == 0
if (toSave.ID == 0)
{
//insert entity into Customers table
context.Customers.InsertOnSubmit(toSave);
}
else
{
//attach entity to Customers table and mark it as "changed"
context.Customers.Attach(toSave, true);
}
//attach or save all "bill" child entities
foreach (Bill bill in toSave.Bills)
{
if (bill.ID == 0)
{
context.Bills.InsertOnSubmit(bill);
}
else

{
context.Bills.Attach(bill, true);
}
//attach or save all "BillingItem" child entities
foreach (BillingItem billingitem in bill.BillingItems)
{
if (bill.ID == 0)
{
context.BillingItems.InsertOnSubmit(billingitem);
}
else
{
context.BillingItems.Attach(billingitem, true);
}
}
}
}

Not very complicated, but a lot of typing. And that’s only for a trivial database scheme and one single entity type. Imagine you were implementing the database layer for several dozen entity types with a few dozen foreign key relationships. You would have to write dozens of nested foreach loops for every single LINQ entity you need a DAL Repository class for. This is not only tedious, but also error-prone. Whenever you add a new table, you’d have to add a few dozen foreach loops to various DAL Repository classes.

How I avoided all these problems

After quite a bit of online research, I implemented a class called RepositoryBase that you can use to quickly implement your data layer that works fine with the examples shown above.

In order to use it, you must first instruct the Object Relational Mapper to generate serializable LINQ entities: Open your dbml file in Visual Studio, left-click somewhere in the white area, and set “Serialization Mode” to “Unidirectional” in the “Properties” panel:

Now you can derive from RepositoryBase to implement your own Repository:

public class CustomersRepository :
//derive from RepositoryBase with the entity name and
//data context as generic parameters
DeverMind.RepositoryBase
{
override protected Expression<Func<Customer, bool>> GetIDSelector(int ID)
{
//ID needs to be the entity's ID column name
return (Item) => Item.ID == ID;
}
}
public partial class Customer
{
public static RepositoryBase CreateRepository()
{
//create and return an instance of this entity type's repository
return new CustomersRepository();
}
}

Do this for each of your entity types, and you have a data layer working seamlessly in disconnected mode. Your derived Repository classes automatically implement the following methods:

As a small bonus, you can also see the SQL commands that were run against the database by ProviderBase in your debug output console when debugging your application. Thanks to Kris Vandermotten for the handy DebuggerWriter component, which is used by RepositoryBase for the SQL debug output!

There’s no free lunch…

There is no significant performance penalty for the Load operations, but there is a bit of reflection going on behind the scenes when you are calling the Save or Delete
methods.

For the vast majority of your DAL needs, this probably has no significant impact on your application either. However, if you are performing a lot of update / insert / delete operations, especially with lots of nested child entities involved, then you might want to hand-code your own Save / Delete functions for the Repository classes of those child applications as described above. All Save / Delete functions are virtual, so you can easily override them.

Also, please note that RepositoryBase does not support recursive save or delete operations with circular dependencies.

Conclusion

This article and the included source code provide a simple, convenient and extensible way to implement your multi-tier LINQ data layer CRUD methods. It works in disconnected mode and supports saving and loading of nested child entities. There is a small performance penalty on Save and Load operations, but you can override those for those Repositories where Save or Load performance is critical.

For everything else, you’re good to go with just a few lines of code.

Source Code

The updated source code for this article can be found here.

Feedback Wanted!

Thanks for your interest in this article. If you have any hints, questions or suggestions, please let me know. I’m using this class on a daily basis and am therefore always interested on how to improve it even further.

One thing that still puzzled me after reading and trying to follow the chapter was how to create complex custom ViewModels (as opposed to putting all data in the ViewData dictionary or using vanilla Linq to SQL entities). Scott mentions on page 107 of the book that you “might have the action method update a ViewModel object with the form-posted data, and then use the ViewModel instance to map or retrieve an actual domain model object”, but there is no actual example of how this would look in source code.

For example, let’s assume you have an edit action method with the following view:

So your edit form displays data coming from a Linq entity representing a customer (FirstName, LastName, Email, Country, AccountType), but you also need SelectLists to populate the Country and AccountType DropDownLists.

The simple, but untyped approach: the ViewData dictionary

The simplest approach is to use the Customer Linq entity as ViewModel and to put the two SelectLists in the ViewData dictionary. This works fine, but I dislike the fact that there is no type-safety for the two SelectLists. Instead you have to use a type cast from object to SelectList:

<label for="CountryCode">Country</label><br />
<%= Html.DropDownList("CountryCode",ViewData["Countries"] as SelectList)%>

<%= Html.ValidationMessage("CountryCode", "*")%>

The fully typed approach: Custom ViewModels

So you want fully typed model data, but the linq entity does not hold all the data you need to render the view. Since you don’t want to clutter my Customer Linq to SQL entity with two properties that return the two SelectLists, the only alternative to get a fully typed view is to use a custom ViewModel:

public class CustomersFormViewModel
{
public SelectList AccountTypes { get; set; }
public SelectList Countries { get; set; }
public Customer Customer { get; set; }
}

Note that the ViewModel is not a mere Linq entity anymore. Instead, it contains the one Customer Linq entity instance, plus the two SelectLists for my DropDownLists.

Now you can implement your view without using any typecasts:

<p>

<label for="Customer.FirstName">

FirstName:</label><br />

<%= Html.TextBox("Customer.FirstName")%>

<%= Html.ValidationMessage("Customer.FirstName", "*")%>

</p>

<p>

<label for="Customer.LastName">

LastName:</label><br />

<%= Html.TextBox("Customer.LastName")%>

<%= Html.ValidationMessage("Customer.LastName", "*")%>

</p>

<p>

<label for="Customer.Email">

Email:</label><br />

<%= Html.TextBox("Customer.Email")%>

<%= Html.ValidationMessage("Customer.Email", "*")%>

</p>

<p>

<label for="Customer.CountryCode">

Country</label><br />

<%= Html.DropDownList("Customer.CountryCode",Model.Countries)%>

<%= Html.ValidationMessage("Customer.CountryCode", "*")%>

</p>

<p>

<label for="Customer.AccountType">

AccountType:</label><br />

<%= Html.DropDownList("Customer.AccountType",Model.AccountTypes)%>

<%= Html.ValidationMessage("Customer.AccountType", "*")%>

</p>

I was wondering if the MVC framework can automatically map the form values and reconstruct a CustomersFormViewModel. In other words, can I simply implement a strongly typed POST edit action method and receive a fully populated ViewModel as a parameter like this:

//POST: /CustomersController/Edit

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Edit(CustomersFormViewModel model)
{
//validate data, save customer, handle validation errors...
}

The answer is yes! The MVC framework even maps object hierarchies of any depth as ViewModels.

How not to do it

This is all really easy, but still there were few things that threw me off at the beginning.

The ViewModelBinder only maps properties, not public fields. A ViewModel like this cannot be mapped:

public class CustomersFormViewModel
{
public electList AccountTypes;
public SelectList Countries;
public Customer Customer;
}

The names of your POSTed form values must match the object hiearchy you want them to be mapped to. Something like this will not work:

<p></p></p></p></p></p></p></p></p></p></p>

<label for="FirstName">

FirstName:</label><br />

<%= Html.TextBox("FirstName",Model,Customer,FirstName)%>

<%= Html.ValidationMessage("FirstName", "*")%>

</p>

In hindsight both restrictions are perfectly logic and reasonable, but it’s easy enough to do it wrong nevertheless and also quite difficult to figure out what went wrong if binding does not work. Hopefully this article will help you avoid any problems with using Custom ViewModels with POST action methods.

Most of my Linq entities have a version attribute to speed up database operations, and sometimes the entities are not only displayed, but also updated and saved back to the database. The first time I tried this, I got the following exception:

A first chance exception of type ‘System.Data.Linq.ChangeConflictException’ occurred in System.Data.Linq.dll

The reason for this is that I was not displaying the version anywhere in the Detailsview. When saving the entity back to the database, the ObjectDataSource created a new entity with default values for all properties that were not bound to any datafields in the DetailsView. So, the entity was re-instantiated with Version==null and when trying to update the database table for the Linq entity, Linq was looking for a row with a 0 version column.

I thought I might work around this by simply version property of the Linq entity to an invisible Column in the Detailsview. But that only gave me a new exception when trying to update the entity:

Sytem. InvalidOperationException: Cannot convert value of parameter ‘Version’ from ‘System.String’ to ‘System.Data.Linq.Binary’

The reason for this is that the Version attribute in Linq entities is of the type System.Data.Linq.Binary, which can be converted to a string, but not back from string to System.Data.Linq.Binary.

It took me quite a while to find at least some workaround for this problem. A working – but somewhat awkward – solution is to create a VersionString propery in each entity:

public partial class Customer
{
public string VersionString
{
get { return _Version.TimestampToString(); }
set { _Version = value.StringToTimestamp(); }
}
}

public static class DateTimeExtensions
{
public static string TimestampToString(this Binary binary)
{
return Convert.ToBase64String(binary.ToArray());
}
public static Binary StringToTimestamp(this string s)
{
return new Binary(Convert.FromBase64String(s));
}
}

Then I bound the VersionString to a hidden field in the DetailsView and the problem was gone. But this solution is not ideal since it requires the VersionString property to be defined for every single Linq entity type that uses a timestamp.

But wait, there’s a much easier way, I stumbled across this solution while playing around with Detailsview a few days ago: Simply add the Version propery to the DataKeyNames property of the DetailsGrid. For example, if your DataKeyNames propery is usually DataKeyNames=”ID”, write DataKeyNames=”ID,Version” instead.

This way the DetailsView serializes the Version property to it’s view state and deserializes it again when the entity has to be recreated. No need to fiddle with the VersionString approach above.

It’s been a while since I posted the first version of my generic base class for LINQ2SQL data layers. The idea behind this class was to provide a quick and simple way to implement a repository with LINQ2SQL and therefore also a solid foundation for implementing your n-tier architecture data layer. If you missed the article, you can read more about the base class here.

The version I previously posted has worked fine for me, but it was still lacking a way to retrieve the ID and version attributes of saved entities. Due to a typo, it also did not work with entities that have more than one unique identity column. Thanks to Mike and Fabrizio for pointing out these limitations!

Version 0.2 available here fixes both of these issues:

Download RepositoryBase Demo Website

Download RepositoryBase Source Code Only