LINQ2SQL "IS" the DAL

When I first started off with LINQ to SQL, my first intincts were to wrap it in a data acces layer just like we had on many previous projects with ADO.NET, but after using it for a short while I realised one important thing - LINQ to SQL is the Data Access Layer.

The generally accepted method of writing applications in .NET was to have 3 tiers - presentation, business and data. Basically, you had Winforms or ASP.NET in your presentation tier, .NET in the business tier and ADO.NET/SQL Server in your data tier.

Usually in the data tier, stored procedures would be created for CRUD operations and other business logic. ADO.NET code would them written to wrap these stored procedures that service the business tier.

This often ended up being quite a lot of T-SQL and .NET code, and because of this it could take quite some time to get just a single vertical slice of functionality running. It would also mean a lot of code to maintain after the product was shipped and bugs/enhancements were made.

With LINQ to SQL, a lot is simplified (although there's still plenty of room for improvement). There's no need to write tedious CRUD stored procedures which also means that there's no need to write the code to wrap the stored procedures.

In my opinion, if you go down the route of putting a layer around the LINQ to SQL (the DAL) you are making a mistake. You are adding extra code where it's not needed and reducing productivity and adding to maintenance later on.

The way I see it, there's no point - there is nothing to gain by wrapping LINQ to SQL up in layers, instead embrace it's elegance by exposing it directly to the business layer and reduce the amount of code you write significantly. Mix it with your business logic - allow it to save you the time which is much better spent in other area's rather than the plumbing.

Either use the LINQ to SQL entities as your Data Transfer objects or use them as your business entities - either way your still saving on code.

Of course LINQ to SQL is not perfect, but it's definately a step in the right direction.

In Summary, this:

Presentation -> Business -> DAL --> ADO.NET --> TSQL --> DATA

Becomes this:

Presentation -> Business -> Linq2SQL --> DATA

Cheers

Matt.