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?


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?


4 Answers 4


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.


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.

  • I agree, LINQ to SQL is just a query language that can prevent you from writing a lot of plumbing code. It doesn't encapsulate data access in your application like a DAL should.
    – neontapir
    Nov 1, 2011 at 17:08
  • I was referring to LINQ to Entities really. I also use plenty of LINQ to Objects but I consider that to be business logic. I understand the behind-the-scenes difference between Entities and LINQ to SQL, but I've never used LINQ to SQL. Are there any differences in syntax?
    – Connell
    Nov 1, 2011 at 17:09

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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.