實體框架體系結構中的有界（Db）上下文

Question

我剛看過Julie Lermans關於在EF中使用有界上下文的視頻（http://www.pluralsight.com/training/Courses/TableOfContents/efarchitecture），我現在正試圖找出實現它的最佳方法（使用POCO） 。 我看到的兩個選項是要么有一個edmx模型定義所有內容，然后手工繪制DbContexts以包含適當的實體，或者為每個上下文分別使用edmx模型並使用自動創建的DbContexts。

有沒有人認為哪個是最好的或任何利弊？

恕我直言：對於單個模型，它是更少的類和更多的代碼重用（盡管這些類是自動創建的，所以實際上它只是手動復制的額外功能），但我會有很多在一個地方的課程和需要專業的課程，每個課程都必須有不同的名稱。 例如Customer，CustomerForFunctionalityX，CustomerForFunctionalityB。

對於單獨的模型，我可以對進入上下文的內容更嚴格，因為刪除屬性不需要是一個全新的實體，並且我可以根據需要命名所有內容（即，即使所有模型都可以使用Customer對象）它在模型之間有所不同），但是現在每個上下文都有完全不同的實體，即使它們都只是映射到同一個表 - 這也使得在上下文之間傳遞它們變得更加困難（但是這不應該經常需要，否則它不需要它意味着上下文已被定義為錯誤）。

Answer 1

我也在嘗試有限的上下文，並遇到了一個（小？）問題的模式。 我最初創建了兩個上下文，一個用於域數據，一個用於審計類型數據（實體更改審計信息和進程信息）。 最初，我發現數據庫只從一個上下文創建表而忽略了另一個上下文。 我假設從基礎上下文中派生出兩個上下文，

    public class BaseContext<TContext> : DbContext where TContext : DbContext

會生成完整的數據庫，但似乎沒有這樣做。

解決此問題的一種方法是創建一個引用所有實體的“主”上下文，但不將其公開給模型。 這工作正常，但現在db模式存在一個小問題。

由於我們的支持人員使用SSMS來調試系統，我認為以與有界上下文相同的方式更改模式是個好主意，所以我在主上下文中指定了模式（O​​nModelCreating（）覆蓋方法與主服務器上下文）：

    modelBuilder.Entity<Address>()
            .HasKey(b => new {b.AddressId,b.EffectiveStartDate})
            .ToTable("Addresses", "Esr");

其中“Esr”是架構。 但是，在嘗試使用有界上下文寫入數據時，會發生錯誤，指示有界上下文使用“dbo”架構。 我相信這有辦法解決這個問題。 我確實有一種嘮叨的感覺，這可能不值得所有的努力。

當然，有界的上下文給應用程序帶來了更清晰的感覺，我喜歡構造代碼以適應域結構的想法，因為這使整體架構更接近規范並且在考慮測試時有所幫助。

另一方面，我的同事程序員在編寫單個整體上下文時是否會在選擇正確的實體時遇到麻煩？

當應用於支持或UAT領域時，上下文的分離更有用，並且這些人必須在整個業務流程方面使用應用程序。

Answer 2

我們現在正在討論這個確切的問題，我也觀看了Julies視頻以及研究DDD。 我希望我的數據訪問能夠反映工作單元，但我們遇到的問題是表名不能用於多個EDMX。

假設我有表Customer，CustomerOrder，Order，OrderInventory，Item。 在一個屏幕上，我只想顯示客戶信息，因此我的EDMX只有客戶。 現在另一個用例是我為客戶開發的所有發票，在這個用例中我有Customer，CustomerOrder，Order，OrderInventory和Item。 我們得到了這個例外：CLR類型到EDM類型的映射是不明確的，因為多個CLR類型與EDM類型“Customer”匹配。 以前發現CLR類型'A.Customer'，新發現的CLR類型'B.Customer'。

你們是如何解決這個錯誤信息的？ 您是否重命名在所有EDMX文件中重復的每個表？

Answer 3

我建議你閱讀有限的背景，以及他們試圖解決的問題。 從有界上下文定義 ：

明確定義模型應用的上下文。 根據團隊組織，應用程序特定部分的使用情況以及代碼庫和數據庫模式等物理表現形式明確設置邊界。 保持模型在這些范圍內嚴格一致，但不要被外界的問題分心或混淆。

擁有單個EDMX模型會違反該顯式邊界。 你可以想象當來自不同環境的團隊在同一個EDMX模型上工作時可能發生的摩擦。 但是，在您的情況下，您可能會覺得上下文之間的顯式邊界和集成的成本太高。 使用共享內核可以讓您在上下文之間共享EDMX模型。

Answer 4

但現在每個上下文都有完全不同的實體，即使它們都只是映射到同一個表

這表明您實際上可能不需要多個有界上下文（BC）。 BC的主要目標是功能凝聚力 ，如果你的模型最終在BC之間產生大量的喋喋不休（換句話說，耦合），那么很可能表明單個BC更合適。 在隔離不同的BC之前，請考慮通過分區到模塊（.NET中的命名空間）來更好地服務您的模型。 有關詳細信息，請參閱實施域驅動設計 。

此外，通常情況下，各種查詢要求可能會使多個BC看起來像是在發揮作用，而實際上您只需要不同的方式來查看同一個實體。 這與完全不同的實體在一起非常不同。 考慮使用讀模型模式來解決這個問題。