實體框架DataContexts

Question

我摔跤的設計，並試圖找出接近它的最佳方式。

我們有很多表，在當前的LinqToSql實現中，我們的DBML的大小很多，非常笨拙。如果可以的話，我想避免重現這種情況。我們根據每個用戶來決定我們的連接字符串，所以很難爲不同的表組創建單獨的dbmls。

我開始使用實體框架，雖然我們不需要代碼優先元素，但我喜歡沒有所有代的輕量級代碼，並且我們不需要可視化映射，因此我一直在考慮生成所有表的代碼文件，然後將它們作爲DbSets添加到DataContext中。

這讓我想到了這裏的最佳實踐，我想問這個問題;

爲每個要使用的表組創建一個DataContext是明智的。即我將有一個模塊，它將負責從5個表中收集數據，它不需要數據庫中的每個表，只有5個。我是否創建包含這5個表的DbContext？如果將來我需要更多，我可以添加它們，但它很輕。

Answer 1

雖然你可能對錶的每個分組單獨背景下，如果你的模型是完全不同的是，你可能要大，或者您的域名尋找到加入了一個抽象層。通過這個，我的意思是有一個包含整個模型的上下文，然後沿着repository pattern的行添加一些內容。對於EF來說，This是一個體面的寫作。

通過這樣做，你會被基本實現兩個目標：抽象出你的數據層，從而騰出實施的擔憂;並允許開發人員僅使用他們所需的實體，可能按aggregate root分組。

但我想澄清一件事。我不一定建議你使用特定的端到端體系結構（即DDD）。我想在這裏做的是提出幾個模式，會給你的靈活性，允許你犯錯誤（失敗正常），同時仍然與您的項目取得進展。

Answer 2

你當然可以做到這一點。您只需像在Linq2SQL中一樣將表添加到edmx模型中，只需添加您需要的5個表，就可以節省其他未跟蹤表的實體跟蹤開銷。實體框架很好地添加了Linq2SQL不具備的雙向導航屬性。我建議使用EF而不是Linq2SQL。

Answer 3

大型DBML模型沒有什麼固有的壞處，EF中的性能影響應該可以忽略不計。

在另一方面，我認爲降低複雜性也適用於實體框架 - 如果你的代碼只需要從數據庫5桌用一切手段創建一個單獨的背景下，只有那些5桌的實體。通過將完全獨立的表分解爲單獨的上下文，您將以明確的方式表達這種分離 - 這些表不依賴於這些表對數據庫中其他表的依賴關係，並且不存在從代碼到不相關實體的依賴關係 - 如果這是我認爲的情況並可能有其他意見），這是要走的路。

但是請記住，如果您需要在另一個上下文中使用這些表中的某些表，那麼您也必須將相應的實體放入該上下文中 - 它可能很難理解相同的表存在於多個上下文中，甚至在上下文之間具有交叉依賴性。這應該避免，因爲它增加了複雜性。