LINQ vs capa de acceso a datos

Siempre me enseñé a manejar cualquier código de acceso a datos en una 'capa' completamente separada de mi código de lógica de negocios y UI. Esta siempre ha sido una muy buena arquitectura para mí y cualquier 'regla' o mejor práctica que veo, aún logra encajar en este estilo de codificación, especialmente en el Principio de responsabilidad única .

Para la mayoría de mis proyectos caseros, usaría mi propio ORM que creé, que siempre tuve la intención de hacer de código abierto. Sin embargo, desde entonces, LINQ estuvo disponible, que era muy similar a la forma en que funcionaba mi ORM (pero ... mejor).

No hay nada que pudiera hacer previamente con mi propio ORM que ahora no puedo hacer con LINQ (excepto bits de la integración REST). Entonces mi pregunta es; ¿LINQ es mi nueva capa de acceso a datos? ¿Ya necesito esta capa? ¿Debería mi BLL hablar directamente con LINQ? ¿O es esta mala práctica todavía?

Editar:

La pregunta original se refería a LINQ to Entities, pero hay muchas respuestas interesantes con respecto a LINQ to SQL. ¿Qué piensan las personas sobre ambos? Supongo que LINQ to SQL realmente no puede reemplazar un DAL, pero ¿podría Entity Framework?

Aunque solo puede poner consultas LINQ en su BLL, esto puede conducir a la duplicación de código. Todavía crearía repositorios que serán un contenedor para las consultas LINQ. Esto separará el código de la base de datos del código BLL y será útil cuando decida modificar su código de acceso a datos (es decir, pasar a Dapper o consultas precompiladas).

También ayudará con las pruebas unitarias , ya que los repositorios se pueden burlar fácilmente.

Todavía podría tener un DAL, solo que podría usar LINQ to SQL en lugar de lo que había usado anteriormente. Así es como lo hago de todos modos. No haga que su BLL use directamente LINQ to SQL para acceder a los datos.

Linq no se trata de acceso a datos, puede usar linq para cualquiera IEnumerable.

¿Has intentado diseñar tu aplicación sin pensar en la base de datos al principio? Es decir, implemente su aplicación y use algún tipo de repositorio. Luego usas cualquier técnica para implementar esos repositorios. De esa manera, tiene una solución totalmente desacoplada donde puede conectar cualquier capa de acceso a datos que desee.

En esa capa de acceso a datos, puede usar su propio ORM o puede usar Linq para sql, no importa mientras la capa de acceso a datos implemente los repositorios que ha definido.

A menos que desee que su "capa de lógica de negocios" aborde las transacciones y el rendimiento de las consultas, todavía es necesario un DAL.

LINQ hace que la declaración de consulta sea un proceso en tiempo de diseño (también conocido como compilador verificado).

Los proveedores de consultas LINQ (como LinqToSql y LinqToEntities) aún realizan la conversión en tiempo de ejecución de esas consultas declaradas a texto sql. Luego, el DBMS todavía realiza la interpretación de consultas en tiempo de ejecución, la generación del plan de consultas en tiempo de ejecución, etc.

Estos son solo una pequeña parte del DAL.