我是否在多個實體框架有界上下文中添加了相同的表

Question

我有一個相當大的數據庫，大約有80個左右的表。 所以我決定將表分成有界上下文，而不是在一個大的edmx文件中包含所有80個表。

所以我有像銷售，客戶等有限的背景。

我的客戶edmx文件中有我的主要客戶表。 但是，我還需要從Sales edmx上下文的customer表中訪問某些字段，而不是所有字段，但只需要1或2個字段（例如，我只需要客戶名稱，而不是整個客戶對象/表）。

我是否必須將整個客戶表添加到Sales edmx文件中？ 這種情況的最佳做法是什么？

Answer 1

我喜歡Julie Lerman對這個主題的看法http://msdn.microsoft.com/en-us/magazine/jj883952.aspx

我使用有界上下文來獲取訪問性能，因為即使使用生成的視圖，使用較小的dbcontexts時上下文的加載時間也會更快。 簡單地訪問訪問模型是非常好的。 性能考慮MS ef網站上的提示： http ： //msdn.microsoft.com/en-us/data/hh949853

BC還允許其他好處，例如限制訪問以匹配業務問題。 如果您嘗試使用不僅在DBSet出現的情況下變化的db上下文，而是嘗試並更改模型視圖，則會出現更大的問題。 我認為最好在EF之外完成並映射。

我使用一個大的SUPERSET Context來管理數據庫創建/遷移。 但不是日常訪問。

較小的DBcontexts用於日常全天訪問數據。

因此，無論如何都要使用有界上下文。 這可以針對SAME數據存儲 。 並回答問題，因為“是的，相同的表（ DbSet）可以出現在許多情況下。

Answer 2

這種方法存在一些潛在的問題（IMO）：

與任何ORM一樣，EF也屬於持久性問題。 因此，它不應該干擾您構建域模型的方式。 事實上，您擁有所有實體，這聽起來像一個持久性存儲，可能表明您的有界上下文重疊或不存在。

試圖轉向更好的結構並不是件壞事:)但是，正如Mark Oreta所說，我可能不會為EF結構而煩惱。

您遇到的主要問題是嘗試從您的域模型中讀取。 這似乎在系統中經常出現，並且使事情變得相當困難。 延遲加載是這種情況的直接結果。 當您閱讀時，理想情況下，您應該使用一個查詢層，該查詢層可以訪問為讀取而優化的查詢存儲（可能是同一個數據庫）。 在您的示例中，您需要在銷售域中使用非規范化的客戶名稱。 那樣就好。 嘗試通過閱讀您的域模型然后嘗試從另一個有界上下文中的域模型中提取數據來實現這一點，這正是導致您痛苦的原因。

如果您沿着分割數據的路線走下去，那么您需要將其分開 。

雖然來自各個BC的數據可能都在同一個商店中，但您應該將數據視為每個BC都有自己的數據庫。 有時候我有一個項目，在不同的文件夾/命名空間（這里是.NET）中有各種各樣的問題（某些層）。 應該可以隨心所欲地將這些問題分解成單獨的組件。 所以他們不應該太緊密耦合。 您嘗試拆分的數據結構也是如此。 實質上，您應該能夠將相關的BC數據拆分到單獨的數據庫中。 在BC中獲取數據的機制是另一回事，我想如果無法解決這個問題，您可能會發現它很難實現。

雖然我不認為從數據方面識別BC可能是最好的主意，但它肯定是朝着正確方向邁出的一步:)

Answer 3

如果您希望能夠使用導航屬性（ Sale.Customer ）從Sales實體訪問Customer實體，則需要將其添加到sales edmx。

將所有表放在單個edmx中並不是一件壞事，只要你創建它，將它用於你想要的動作，然后處理它，對象圖就不會那么大。

或者，如果您想保留有界上下文，則可以在需要時使用存儲庫或其他內容來獲取它。

var customer = customerContext.GetCustomerById(sale.CustomerId);