是否必须将业务对象与实体框架（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推动了这种趋势，因为如果你想要将它们分离，它可能会使开发变得更加复杂。

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

因此，在BL中，以下preudo-code插入一个具有BObject1（1：n关系）的List<BObject2>，如下所示：

 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。