使用Linq to Entities时是否需要单独的数据层？

Question

使用Linq to Entities时，是否仍然需要使用单独的数据层抽象数据库访问，或者可以接受（甚至推荐）直接从代码隐藏中生成Linq查询（自获取，添加，更新，实体框架中已经内置了删除功能和删除功能吗？

Answer 1

我们使用Linq到EF，我们仍然有一个单独的数据层。

部分原因是如果我们不想再使用EF，或者我们需要支持EF不支持的数据库，将来会发生什么。抽象的一部分是每个层都可以在不影响其他层的情况下进行更改。

但也因为我们的数据层比简单加载和保存数据对象稍微复杂一些。从EF加载对象后，它们与EF数据上下文完全断开连接并转换为业务对象。 EF生成的数据对象永远不会暴露在数据层之上。 （这是因为EF对断开连接的客户端 - 服务器应用程序的支持不足，所以我们必须自己管理该部分）

Answer 2

Linq-to-Entities是一个实现细节。数据层旨在将实现从数据交互中抽象出来。如果您发现Linq-to-entities不合适并且您必须更改实现，这可以确保系统的健壮性。因此，是的，您仍然需要一个数据层。

Answer 3

在我看来，实体框架是一个DAL。虽然在某些应用程序中我将它包装起来，因为它仍然是一种特定的技术，我从整个应用程序中尝试抽象特定的技术。因此，如果需要转到另一个或更改业务对象的创建方式，则可以在不影响应用程序其余部分的情况下执行此操作。

你会得到一些回应，因为这真的适用于所有的OR / M工具。

Answer 4

这取决于死线的接近程度，您希望开发的应用程序有多大，可能还有更多。

我会说是的，确实实现数据层。例如：如果应用程序需要使用Oracle数据库（将来的某个时间）运行该怎么办...确实会很快变得丑陋。