實體框架，預測和關係（哦我的？）

Question

所以，我正在研究新的軟件，但我別無選擇，只能對數據庫進行修復。我想在實際框架中使用實體框架。

這裏是我的困境：

• 由於表是很寬，我無法改變這一點，我很可能會大量使用投影的限制，我查詢數據集的寬度。
• 我也想利用導航性能在有意義
• 從我所看到的，有很多人使用模型，其中有對整個項目的單一的DbContext類。

所以，

我權衡這些親的利弊，我想知道既定的最佳做法可能是什麼：

• 使用1的DbContext。
  
  • 這裏可能會有很多「污染」，其中1個上下文類中的數據投影是一堆。這聽起來像它可能成爲維修噩夢。
• 不要讓我的投影dbsets - 只是讓他們普通的舊對象，並選擇新的MyProject {..}到他們。
  • 這爲保持我的預測在特定的模塊集和命名空間的好處，但現在我沒有得到任何導航/延遲加載/等
• 作惡？並使用多個DbContexts？
  • 我不確定這裏的維護故事是什麼樣的，但我開始傾向於這個方向。我最大的問題是，它感覺就像我在逆流而行 - 沒有多少人似乎這樣做，但對於大型系統來說，它似乎是最好的選擇。

想法？

Answer 1

我認爲你必須使用POCO或DTO在不同的應用層之間進行數據傳輸。使用ViewModel將數據發送到View。

考慮在這種情況下使用Repository Pattern和UoW來構建更好和更高效的體系結構。將導航屬性的使用限制在存儲庫中，否則會導致實體繁重，同時跨層轉移（使用POCO或DTO）。

如果你像上面那樣做，那麼我不認爲使用多個DbContexts會給你帶來任何好處。謝謝。