Linq-to-sql to use or not to use

Following on from my previous post I mentioned the problems encountered trying to use an ORM for the first time, specifically linq-to-sql.

In the recent project where my team used Linq-to-sql (L2S) we were using Asp.Net Dynamic Data and we ended up with lots of data access in the code behind.  I plan to cover our experience of using Dynamic Data in an application in a future post but let me say now its not what I expected – and not in a good way.

So the team moved onto another project and we wanted to be able to put a proper layered design in place with a presentation, business logic and data access layers and immediately ran into a problem in that if we wanted to create an app that conformed to good design principles e.g. Dependency Inversion Principle, then we were going to run into a few issues.

Now I know that I’m way behind the curve on the use of L2S as most of the blog posts and articles I’ve been reading are from back in 2007, but I have been having a bit of difficulty finding information about using L2S in a layered and tiered system which worries me since it may be a case of “it doesn’t do it but you can make it do it” which is a code smell to me.

So far I’ve found a few articles and the one thing that strikes me is the amount of additional work that is required to make L2S work in a layered way, I know that it doesn’t support POCO but at the same time simply using it as an ORM seems to be more difficult than I would have hoped.

The following articles are a good summary of the information I’ve found and I’m still looking into this to see what I can find.

Using the IRepository pattern with Linq-to-SQL
Linq to Sql – How-to Separate the entities and the DataContext.
LINQ to SQL Queries out of a Business Layer