是否需要将业务对象与实体框架 (POCO) 对象分离？

Question

在我们的应用程序中，我们将现有 DAL 从 EF 4.0 升级到 EF 5.0。
目前已经实现了通用存储库模式，我们正在使用 POCO 对象作为业务实体。
这些对象使用 WCF 属性进行修饰，因为它们在 Web 服务接口中传递并使用部分类进行扩展，以便添加更多业务和验证方法。此外，每个 POCO 实体都继承自基类“BusinessEntity”和接口“IBusinessEntity”，以便轻松使用泛型存储库方法。

我们计划将业务实体与 POCO 对象分离，以使后者成为只有属性而没有逻辑的普通类。

但是在阅读了该主题之后，目前的技术状态似乎是采用 Code First 方法并直接保留域实体（即使当然不可能对所有情况进行概括）。
Related answer 1, related answer 2.

在我们的例子中，保留带有业务逻辑的 POCO 对象并仅应用与 EF 5.0 (DbContext) 相关的更改是否有意义？或者我们应该在存储库中引入一个映射层？通过这种方式，应用程序将在业务实体上运行，并且存储库层将从外部隐藏 POCO 对象。然而，缺点是引入了复杂性，特别是在处理通用存储库时。

提前致谢。

Answer 1

我想与您分享我对您的问题的经验，尽管我来这里是为了寻找另一个相关问题的解决方案。

我读过的大多数人和文章都说将 EF POCO 用作业务对象……对我来说，似乎 EF 推动了这种趋势，因为如果你想将它们解耦，它可能会使开发变得更加复杂。

您说，您的系统中已经有带有 POCO 的 EF。好吧，我希望你从相反的角度来看待它：我们有一个项目，在开始时，DAL 使用我们自己用纯 ADO.NET 编写的基本“数据库处理程序”和我们自己的业务类；但现在我们也尝试支持实体框架（所以我们加载旧的数据库处理程序或 EF ......也许稍后我们将切换到 EF）。由于我们想保持数据库不变，我们采用数据库优先的方法；目前，我们无法找到一种方法来在现有业务对象和 POCO 之间建立更轻松的连接（目前我们使用简单的“投影”进行转换）。

因此，在 BL 中，插入具有 List<BObject2>（1:n 关系）的 BObject1 的以下前置代码如下所示：

 this.UnitOfWork.ExecuteTransaction(() =>
 {
    bObject1_Repository.InsertBObject1(bObject1);

    foreach (var bObject2 in bObject1.ListBObject2)
       bObject2_Repository.InsertBObject2(bObject2);
 });

一切都对我们旧的“数据库处理程序”有好处；我们重用相同的事务并隐式地使用相同的连接......但现在对于 EF，变得非常棘手。为了插入任何 bObject2，首先你可能想要一个自动生成。 bObject1 的 UID（在第一次插入后已经知道）...这在 EF 中不可用，除非您在第一次插入后过早调用 SaveChanges。一旦涉及多个“SaveChanges”调用，您就必须考虑这些事务会发生什么。分布式事务 (DTC) 可能是一个小问题……当我们想要支持 Oracle 数据库时，我们的项目就是这种情况……实际上我们被困在这里了。

我希望我也能帮助你从另一个角度看待事物......

旁注：

很高兴听到在 EF 和 Oracle 方面有经验的人对 BL 中事务使用的意见； my question 也可以帮助我。