實體框架和應用程序體系結構（鬆耦合等）

Question

我正在考慮在新項目中應用實體框架，因爲我喜歡它的OR/M-API以及存儲/概念模型映射功能（當然還有Linq和實體SQL）。

但是如果EF實體被用作兩者中的數據持有者，如何在UI層和業務層之間實現鬆耦合。如果在駐留在用戶界面中的時候將這些實體附加到它們的ObjectContext中，那麼UI可能會繞過業務層並直接連接到數據庫。如果我將實體從ObjectContext中分離出來，然後將它們傳遞給用戶界面，將不會有更改跟蹤，因此我必須「重放」業務層中的所有更改，以便將它們保存到數據庫中（難以實現，尤其是親子關係）。雖然我不希望業務層降級到「對象樹持久性引擎」，但有些情況下具備此功能會有所幫助。

這當然也適用於其他OR映射器，但幾種替代產品似乎有更好的分離/附着機制。

Answer 1

谷歌「實體框架」和「不信任投票」，看看你得到什麼。

Answer 2

「重播」更改比您想象的要容易。以下是您需要做的一般概述：

1. 將實體實例的「原始」版本存儲，然後將其分離並將其交給UI。
2. 讓用戶界面做它的事情。
3. 當您想要將UI所做的更改持久保存到數據庫時，請取出您存儲的原始版本，並將其附加到EntityContext。將由UI返回的修改版本中的更改應用到此實例。現在SaveChanges。實體框架將處理三路合併。

Answer 3

我不知道任何ORM能夠正常處理您希望具有平臺獨立性的n層解決方案。當一切都在ObjectContext中發生時，當你有一個n層解決方案（物理分離，WCF/XML Web服務調用）時，你必須做一些準備工作以使對象正常工作。

通過使用Repository模式分離出Ef上的api依賴關係（http://blog.keithpatton.com/2008/05/29/Polymorphic+Repository+For+ADONet+Entity+Framework.aspx），可以實現鬆耦合。但是，如果您直接在UI層中使用EF類，除非您決定深入瞭解EF與純C＃類（POCO）行爲的世界，否則您將對某些類型（如EntityReference，EntityKey和EntityObject）具有依賴關係。這似乎比它對我來說更加麻煩。

Answer 4

ADO.Net團隊的Daniel Simmons給extension method "AttachAsModified"附加了一個已被修改的對象。

這不像重播更改那麼聰明，但這使得它：我將它用於示例項目。