实体框架和应用程序架构（松散耦合等）

Question

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

但是，如果将EF实体用作两者中的数据持有者，如何在UI层和业务层之间实现松散耦合。如果我将实体在其驻留在UI中时将其附加到其ObjectContext，则UI可能会绕过业务层并直接连接到数据库。如果我将实体从它们的ObjectContext中分离出来，然后再将它们传递给UI，那么就不会有任何转换，所以我必须“重放”业务层中的所有更改，以便将它们保存到数据库中（很难实现，特别是亲子关系）。虽然我不希望业务层降级为“对象树 - 持久性引擎”，但有些情况下有这种能力会有所帮助。

这当然也适用于其他OR-mappers，但是一些替代产品似乎有一些更好的分离/附加机制。

Answer 1

“重播”更改比您想象的更容易。以下是您需要做的概述：

1. 在分离实体实例之前存储实体实例的“原始”版本并将其交给UI。
2. 让UI做自己的事。
3. 如果要将UI所做的更改保留到数据库，请使用您存储的原始版本，并将其附加到EntityContext。将UI返回的修改版本中的更改应用于此实例。现在SaveChanges。实体框架将处理三向合并。

Answer 2

我不知道任何ORM能够优雅地处理您希望具有平台独立性的n层解决方案。当一切都在ObjectContext中发生时，EF运行良好，当你有一个n层解决方案（物理分离，WCF / XML Web服务调用）时，你必须做一些管道以使对象正常运行。

您可以通过使用Repository模式来分离出对Ef（http://blog.keithpatton.com/2008/05/29/Polymorphic+Repository+For+ADONet+Entity+Framework.aspx）的api依赖关系来实现松散耦合。但是，如果直接在UI层中使用EF类，则将依赖于某些类型，如EntityReference，EntityKey和EntityObject，除非您决定深入研究使EF与纯C＃类（POCO）一起运行的世界这对我来说似乎比它的价值更麻烦。

Answer 3

ADO.Net团队的Daniel Simmons给了一个extension method "AttachAsModified"来附加一个已被修改过的对象。

这并不像重播更改那么聪明，但这就是：我将它用于示例项目。

Answer 4

谷歌“实体框架”和“不信任投票”，看看你得到了什么。