EntityFramework，數據庫和域

Question

我的領域是由兩個類組成的。 首先是耐心。 第二個是注射。 人可以有許多注射實例。

這引起了有關某些OOD，關系數據庫設計和ORM（特別是EntityFramework）的體系結構問題：

我希望患者可以擁有注射屬性列表，並且注射可以具有患者屬性。 這看起來像是一個好的面向對象的設計。

該設計（首先使用EntityFramework代碼）將映射到兩個表：Patients表和Injections表。 進樣表將在患者表中具有指向行的外鍵。

到現在為止還挺好。

現在，讓我們假設一個如上所述的數據庫案例，其中1名患者進行了100,000次注射。

當我向該患者詢問DbContext時，它將檢索患者數據，並且注射列表將僅按需加載。

這看起來像一個潛在的問題。 我對任何潛在的Patient用戶說-“嘿，您有注射列表，請使用它們！只能使用-myPatient.Injections，它們會神奇地出現”。

但是，通過公開此屬性，我潛在地使患者的用戶能夠運行非常繁重的查詢，這甚至可能不是應用程序需要。

一種可能的解決方案是從患者分類中刪除“注射”列表。 關於數據庫，映射將保持不變，為了查詢患者的注射情況，我將使用具體服務。 但是現在我有一個Patient類，它不能很好地代表我的領域。

另一個可能的解決方案是將從EF上下文返回的每個對象映射到另一個淺對象。 我只會映射我需要的內容，而不會向用戶公開不需要的數據。 這種方法將導致重復並維護類之間的映射。

您如何看待這個問題？

分享您的知識:)

Answer 1

這完全取決於您實際如何公開對象。

如果對象是在域模型級別公開的，則可以，對注入coul的延遲加載查詢可能會加載並實現10萬個項目。 但是，嘿，創建10萬個實例並將其插入或執行任何此類繁重的工作也會非常昂貴。

這意味着，如果您擔心潛在的濫用，請不要將域模型暴露給潛在的客戶。 取而代之的是，讓您的服務層甚至可能通過http公開，這樣您就永遠不會遇到此類問題，例如，大型集始終會通過分頁公開。