Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

migrated from stackoverflow.com Nov 3 '11 at 7:24

This question came from our site for professional and enthusiast programmers.

add comment

4 Answers

up vote 6 down vote accepted

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.

share|improve this answer
add comment

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.

share|improve this answer
    
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 '11 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 Watkins Nov 1 '11 at 17:09
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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