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?
Best Answer
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.