LINQ vs Data Access Layer

Question

I've taught myself always to handle any data access code in a completely separate 'layer' to my business logic and UI code. This has always been a very good architecture for me and any 'rules' or best practices I see, still manage to fit into this style of coding, especially Single Responsibility Principle.

For most of my home projects, I'd use my own ORM I created, which I always intended to make open-source. However since then, LINQ became available, which was very similar to the way my ORM worked (but.. better).

There's nothing that I could previously do with my own ORM that I can't now do with LINQ (except bits of the REST integration). So my question is; is LINQ my new Data Access Layer? Do I need this layer at all anymore? Should my BLL just talk directly to LINQ? Or is this bad practice still?

Edit:

The original question was referring to LINQ to Entities, but there are many interesting answers regarding LINQ to SQL. What are peoples thoughts on both of them? I gather than LINQ to SQL can't really replace a DAL, but could the Entity Framework?

Answer 1

Although you can just put LINQ queries in your BLL this may lead to code duplication. I would still create repositories that will be a wrapper to LINQ queries. This will separate Database code from BLL code and will be useful when you decide to modify your data access code (ie. move to Dapper, or to precompiled queries).

It will also help with unit testing, as repositories can be easily mocked.

Answer 2

You could still have a DAL, only it could use LINQ to SQL instead of what you had previously used. That's how I do it anyway. Don't make your BLL directly use LINQ to SQL to access data.

Answer 3

Linq is not about data access, you can use linq towards any IEnumerable.

Have you tried to design your application without thinking about the database at first? That is, implement your application and use some kind of repository. Then you use whatever technique to implement those repositories. That way you have a totally decoupled solution where you can plugin whatever data access layer you want.

In that data access layer you could use your own ORM or you could use Linq to sql, it doesn't matter as long as the data access layer implements the repositories you have defined.

Answer 4

Unless you want your "business logic layer" to address transactions and query performance, there is still a need for a DAL.

LINQ makes query declaration a design-time (aka, compiler checked) process.

LINQ query providers (such as LinqToSql and LinqToEntities) still do run-time conversion of those declared queries to sql text. Then the DBMS still does run-time query interpretation, run-time query plan generation etc.

These are just a small part of the DAL.