LINQ与数据访问层

我自学成才，始终在业务逻辑和UI代码的完全独立的“层”中处理任何数据访问代码。对于我而言，这一直是一个非常好的架构，并且我看到的任何“规则”或最佳实践仍设法适应这种编码风格，尤其是“ 单一责任原则”。

对于我的大多数家庭项目，我将使用自己创建的ORM，我一直打算将其制作为开源代码。但是从那时起，LINQ可用了，这与我的ORM的工作方式非常相似（但更好）。

我以前无法使用自己的ORM进行我现在无法使用LINQ进行的任何操作（REST集成的某些功能除外）。所以我的问题是；LINQ是我的新数据访问层吗？我是否需要此层了？我的BLL应该直接与LINQ对话吗？还是这种不良做法？

编辑：

最初的问题是指LINQ to Entities，但是有关LINQ to SQL的答案很多。人们对他们两个都有什么想法？我收集到的信息比LINQ to SQL不能真正替代DAL，但是可以使用实体框架吗？

尽管您可以只在BLL中放入LINQ查询，但这可能会导致代码重复。我仍然会创建存储库，这些存储库将成为LINQ查询的包装。这会将数据库代码与BLL代码分开，并且在您决定修改数据访问代码（即移至Dapper或预编译的查询）时很有用。

它还可以帮助进行单元测试，因为可以轻松模拟存储库。

您仍然可以拥有一个DAL，只有它可以使用LINQ to SQL而不是您以前使用的DAL。无论如何我就是这样。不要让您的BLL直接使用LINQ to SQL访问数据。

Linq与数据访问无关，您可以对任何linq使用IEnumerable。

您是否曾尝试在设计应用程序时不首先考虑数据库？也就是说，实现您的应用程序并使用某种存储库。然后，您可以使用任何技术来实现这些存储库。这样，您将获得一个完全解耦的解决方案，您可以在其中插入所需的任何数据访问层。

在该数据访问层中，您可以使用自己的ORM或使用Linq到sql，只要数据访问层实现您定义的存储库就没有关系。

除非您希望您的“业务逻辑层”解决事务和查询性能，否则仍然需要DAL。

LINQ使查询声明成为设计时（也就是编译器检查）过程。

LINQ查询提供程序（例如LinqToSql和LinqToEntities）仍将那些声明的查询运行时转换为sql文本。然后，DBMS仍会执行运行时查询解释，运行时查询计划生成等。

这些只是DAL的一小部分。