More Linq to SQL pondering's

As has been noted on this blog before, I like the idea of Linq to SQL, but have some real reservations about it's use in an n-tier, real world way.

Rick Strahl has a good piece talking about the DataContext lifecycle. In a nutshell, the problem with the DataContext is that it is a persistent, connected object.

Most other ORM's use a static management object that you connect and disconnect as needed.

The issue with the Linq DataContext is knowing how/when to use it with your business layer. A single global DataContext is not a good idea as it doesn't allow enough flexibility in it's updating mechanism. The general consensus is to create a DataContext per Business Object, do its work and then dispose.

What this means in practice is you will end up having plain old C# objects being populated by Linq to SQL and passed between tiers using collections perhaps. You probably could pass IQueryable<T> objects between tiers, but this has it's disadvantages too.

So it's my conclusion that for real world, n-tier apps, Linq to SQL is far from the best approach, and in fact you shouldn't probably use it at all. I am going to stick to the collection based approach that I have always used, and maybe use Linq or Linq to SQL as purely a Data Layer and a nice querying language.

Unfortunately, from what I have seen from the Entity Framework has the same problems as Linq to SQL. Hopefully it's something Microsoft can remedy in the future. I think if they listen to the community they will have to.