使用Linq转换实体时是否需要单独的数据层?

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

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

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

LINQtoEntities是一个实现细节。数据层旨在将实现从与数据的交互中抽象出来。这确保了系统的健壮性,如果您发现Linq与实体不匹配,并且必须更改实现。因此,是的,您仍然需要一个数据层。

在我看来,实体框架是DAL。虽然在一些应用程序中,我已经包装了它,因为它仍然是一种特定的技术,我尝试从整个应用程序中抽象出特定的技术。因此,如果需要转到另一个或更改业务对象的创建方式,您可以这样做,而不会影响应用程序的其余部分。

您会得到一些有趣的响应,因为这确实适用于所有OR/M工具。

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

我会说是的,实现一个数据层 . 例如:如果应用程序需要使用Oracle数据库(将来某个时候)运行该怎么办。。事情肯定会很快变得糟糕。