2013-06-19 83 views
1

我的域由兩個類組成。 第一個是病人。 第二個是注射。 人可以有很多注射實例。EntityFramework,數據庫和域名

這就提出了關於一些OOD,關係數據庫設計和ORM(具體的EntityFramework)架構的問題:

我想,病人將舉行注射財產清單和注射將舉行一個病人屬性。這看起來像一個很好的面向對象的設計。

這種設計(使用的EntityFramework第一代碼),將映射到兩個表:患者表,注射表。 Injections表將在患者表中的一行中有一個外鍵。

到目前爲止這麼好。

現在,讓如上所述,用1名患者具有100000次注射假設一個數據庫的情況。

當我問的DbContext這個病人就會retrive患者數據和注射的名單將只需要加載。

這看起來像是一個潛在的問題。我對Patient的任何潛在用戶說:「嘿,你有一個注射清單,使用它們!只有這樣做 - myPatient.Injections,它們會神奇地出現」。

然而,通過暴露這個屬性,我可能使患者的用戶運行一個非常沉重的查詢可能甚至是應用程序的需要。

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

另一種可能的解決方案是將從EF上下文返回的每個對象映射到另一個淺層對象。我只會映射我需要的內容,而不會將不需要的數據暴露給用戶。 這種方法會導致重複和維護類之間的映射。

您對這個問題有什麼看法?

分享您knowledege :)

+1

請給我們一些代碼。 –

+0

如果你想完全控制你的SQL,那麼不要使用實體框架,編寫一個使用存儲過程的數據訪問層(DAL),你將對「重」和「輕」查詢的使用有更大的控制權。 –

回答

1

這一切都取決於你如何實際暴露你的對象。

如果對象是在域模型級暴露,那麼,延遲加載查詢到注射couls可能加載和兌現10萬項。但是,嘿,創造10萬個實例並插入它們或做任何重要的事情也可能是昂貴的。

這意味着,如果你擔心可能被濫用,不要暴露域模型的潛在客戶。相反,有你的服務層,可能甚至暴露在HTTP之上,以便你永遠不會遇到這樣的問題,例如 - 大集合總是會被分頁暴露。

相關問題