Sql – Linq to SQL & Logical partitioning (DAL, BLL)

blldata-access-layerlinqlinq-to-sql

We're going to be rebuilding one of our sites in .Net. I've read many articles and really like the idea of separating our project into a data access layer (DAL), Business logic layer (BLL), and presentation layer (we're coming from classic ASP so this is a massive step for us). I also really like Linq to SQL.

Since Linq to SQL is aimed at rapid development, is it really possible with Linq to SQL to have a DAL, BLL, and presentation layer? With Linq to SQL would the DAL return the entities or the linq code which could be possibly modified in the BLL? The relationship between the DAL and BLL with Linq to SQL seems to be a fuzzy topic with no consensus – and since this is such a big jump for us I definitely want to have a good game plan before diving into anything.

Typed Datasets seem more equipped for this, but if I can get something similar with Linq I'd go that route.

I'd like to stay away from nHibernate and other 3rd party libraries.

Best Answer

We're building exactly what you described, and we're using L2S to do it. Agreed that the relationship between the DAL and BLL is a bit fuzzy, but we have a distinct BLL and a distinct DAL. All our logic is in the BLL and all data retrieval/modification is done via calls to the DAL (using LINQ calls).

Our app uses no typed datasets. We've built entity classes to represent our objects. Now that I've spent a couple months building part of this, I don't see us (me) ever going back to datasets.

Also, I wouldn't get hung up on L2S being "aimed at rapid development". This makes it sound like a prototyping tool. We're finding it to be an industrial strength tool. This might be contrary to what Microsoft might now be saying about it, since they would rather people use EF.

Randy