設計決策：多個EF EDMX文件

Question

如果您使用了實體框架，那麼您知道EDMX很酷。你也知道它會變得巨大而且幾乎難以控制。

當它變大時，很容易爲數據庫中的每個Schema創建第二個EDMX或第三個EDMX（就像舉例一樣）。

這樣的分離將有助於組織您的EDMX，但它可以分離相同名稱空間中實體的上下文。

此外，單獨的EDMX文件可能會導致跨EDMX文件的JOIN操作導致冗餘的冗餘數據庫通信。

但事實是，EDMX越大，使用越困難。確保它是正確的越困難。它更容易被打破。

您是否將您的EDMX文件分開？你有什麼經驗法則？

Answer 1

爲分裂您的EDMX需要將 如果您有一個以上的項目，用一組實體的一個例子 而另一些具體項目，你願意放棄具有之間的導航性能部分（並且只保留暴露的FK）。

如果您想分開維護EDMX，您可以自動合併EDMX，但可以向所有人開放一個上下文並將其作爲一個查詢。這要求他們共享相同的名稱空間。

Answer 2

我們只需要在單個解決方案中使用兩個單獨的EDMX。 EDMX針對領域特定的模型實體發生了這種分離，另一種則發生在我們所有解決方案（支付作爲示例）中更常見的情況。從邏輯上講，您可以對我們說這是在數據庫模式級別，儘管這不是分離的硬性規則。

雖然我們沒有對它們進行連接的要求，但我們確實需要事務處理。我們用一個可重用的UnitOfWorkContainer來完成這個任務，這個UnitOfWorkContainer會將EF上下文包裝在一個TransactionScope中。上下文將通過DI注入到容器中，如果容器中存在多個上下文，我們將只使用TransactionScope。

容器本身實現了我們的IUnitOfWork接口，所以它很容易插入到現有的代碼庫中。