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.

Version 1.0 Release Candidate 1 of LINQ to SQL Entity Base released!!!

Hi people,

I've finally made a release candidate for the LINQ to SQL Entity base which can be found here

A number of things have been done recently to it, namely:
- Added two static helper methods for serialization/de-serialization of entities.
- Now automatically returns KnownTypes if Entity Base class is in the same assembly as your Entity classes.
- You can now set the initial state of the root entity (e.g. New or Deleted)
- Demo is now in the form of a Client/Server architecture, with WCF used for communication.
- Added "LINQEntityState" property which returns an enum indicating the state of the entity.

Oh, and i've re-written the home page to include a list of "How To's" covering a lot of the questions i've been asked. Find it here


Enjoy!

Cheers

Matt.