跨多個項目使用EntityFramework

Question

我正在處理如何最好地在多個Visual Studio項目中打破域模型。我正在使用EntityFramework 4和Enterprise-type模式來合理化可以重用於各種應用程序的系統。最終，我想最終得到一組可以在Web應用程序中重用的混合匹配DLL類庫。

Sor遠，我有一個標準的數據庫模式，其中包含用戶信息，基本的CRM，基本的CMS和輕量級的電子商務平臺。

CRM /用戶表是系統的核心。 CMS和電子商務平臺利用CRM用戶表。我想定義CMS和電子商務域模型鏈接/派生自的核心域模型。

到目前爲止，我有三個Visual Studio項目：

• MyNamespace.Model.Core
• MyNamespace.Model.CMS
• MyNamespace.Model.Commerce

在每這些模型是一個實體框架域模型EDMX文件。 EDMX包含所有相關的表格。這意味着CMS和Commerce項目的EDMX文件包含一些用戶表。理論上我可以有一個大的EF模型，並將所有的POCO放在一個類中，但這不是很有擴展性。

這些項目還包含每個表的POCO（這些應該可能在一個單獨的項目中，但是在事物排序之前，它們可以保持在原來的位置！）。

當我在具有Unit of Work的服務層中使用域模型時，我只想使用一個ObjectContext（實際上是一個定位EF ObjectContext的IObjectContext包裝器）。出於這個原因，我給每個EDMX文件提供了相同的實體容器名稱和名稱空間。

問題：

1. 這是做正確的事嗎？
2. 如果具有相同容器名稱的相同名稱空間中存在EF模型（儘管跨越不同的項目），如果在這些不同模型中重複表/實體（例如，客戶），這會導致問題嗎？

Answer 1

那麼EF是非常新的，幾乎所有人都喜歡你正在試驗和尋找創造更好系統的新方法。所以不會有任何直接的答案，但我可以把我的想法和我已經遇到的問題。

多EDMX

1. 共享實體問題建立更通用的邏輯將是困難的，因爲你最終將不得不在多個方面相同的命名實體。
2. 如果他們將要存儲在一個數據庫中，那麼將來您可能需要兩個不同上下文中的實體之間的連接和關係。
3. 寫基於通用邏輯的反射將不可能。
4. 跨多個環境的工作單元將會變得複雜。
5. EF已經實施了工作單元，而RIA服務將成爲一個不錯的候選人，而不是重新實現整個事情。
6. 將所有內容保存在一個上下文中將允許您構建可擴展的應用程序。而且大多數代碼都是自動生成的，所以它不會有太大的區別。
7. 我們確實嘗試過這一點，我們意識到後來需要大量的膠水代碼，事情變得骯髒，因爲重複的代碼和報告成了大麻煩，我們最終將所有內容都移到了一個上下文中。

如果我打算將所有內容都存儲在一個數據庫中，我將它看作只是一個存儲庫。

Answer 2

公平點，一些意見：

1. 這是最大的問題，據我可以看到。我想這可以通過適當使用（例如）CRM.Person和適當的Commerce.Person來解決。我認爲我正在嘗試的是EF域模型（S）位於其下的普通POCO模型。我並不太在乎EF模型是如何構建的，而不是它應該是合理的結構。

2. 再次，下一個最大的問題。通過在不同的上下文中重複實體來解決某種程度的問題，但這意味着某些導航屬性不可用。例如，一個CRM.Person不會擁有Commerce.Person所擁有的訂單，運輸等屬性，即使他們是數據庫中的「相同」人員。

3. 基於反射的邏輯（目前）對我來說並不重要。

4. 同意。因此，爲什麼我想以某種方式來達到一個上下文

5. 工作單元實際上是一個IUnitOfWork，並被存入存儲庫，並且需要獨立於EF。

6. 不同意。這個想法是要找到一個核心應用程序，如果有必要可以擴展。例如，未來的項目可能涉及到劇院預訂。這將與商業核心綁定，但我不想重新編程商務應用程序來解決它。就我而言，重建EDMX模型並不理想。可能是唯一的方法。

   1. 我可以看到如何發生！

這乍看起來，好像這是EF的缺點，雖然有可能是沒有做我想要做一個很好的理由。也許微軟應該包括某種方法，在運行時合併具有相同容器名的兩個EDMX域模型。有效地（並且爲了一個更好的詞）EDMX模型會變得「偏袒」，只要沒有任何衝突，我不會看到太多錯誤呢？ 「