我正在考虑在新项目中应用Entity Framework，因为我喜欢它的OR / M-API以及存储/概念模型映射功能(当然还有Linq和Entity SQL)。

但是，如果将EF实体用作两者的数据持有者，那么如何在UI层和业务层之间实现松散耦合。如果我在实体驻留在UI中时将它们添加在其ObjectContext上，则UI可能会绕过业务层并直接连接到数据库。如果在将实体传递给UI之前将它们从ObjectContext中分离出来，将不会进行更改跟踪，因此我必须"重放"业务层中的所有更改才能将其持久化到数据库中(很难实现，尤其是使用亲子关系)。尽管我不希望业务层降级为"对象树持久性引擎"，但在某些情况下，具有此功能会有所帮助。

这当然也适用于其他OR映射器，但是几种替代产品似乎具有更好的分离/添加机制。

解决方案

回答

Google的"实体框架"和"不信任票"，看看你能得到什么。

回答

"重放"更改比我们想象的要容易。这是我们需要做的一般概述：

• 在分离实体实例并将其交给UI之前，请存储它的"原始"版本。
• 让UI做自己的事情。
• 当我们想要将UI所做的更改持久保存到数据库时，请使用我们存储的原始版本，并将其添加到EntityContext。将用户界面返回的修改后的版本中的更改应用于该实例。现在，保存更改。实体框架将处理三向合并。

回答

我不知道任何要与N层解决方案妥善处理的ORM，而这些平台都希望具有平台独立性。当在ObjectContext中发生所有事情时，EF运行良好，当我们使用n层解决方案(物理隔离，WCF / XML Web Service调用)时，我们必须做一些工作以使对象正确运行。

我们可以通过使用存储库模式来分离Ef上的api依赖关系来实现松散耦合(http://blog.keithpatton.com/2008/05/29/Polymorphic+Repository+For+ADONet+Entity+Framework.aspx) 。但是，如果直接在UI层中使用EF类，则将依赖于某些类型，例如EntityReference，EntityKey和EntityObject，除非我们决定深入研究让EF与纯C类(POCO)一起工作的世界，对我来说，似乎麻烦多于值得。

回答

ADO.Net团队的Daniel Simmons提供了一种扩展方法" AttachAsModified"，用于添加已修改的对象。

那不像重放更改那样聪明，但是做到了：我正在将其用于示例项目。