我認爲這個問題在具有中等大小模型的Web應用程序中很常見。 比方說，我有一個SportCenter類的籃球場列表，當 顯示保留或屬性的籃球場我仍然想顯示 關於它所屬的體育中心的一些信息。ASP.Net MVC，ORM和「重」對象
我使用ASP.Net MVC和NHibernate爲數據層，所以我的問題是： 是值得做NHibernate的加載整個SportCenter實例（實際上 包含的集合都懶加載但仍然類「重」） 與我的BasketballField及其相關信息只是爲了展示 體育中心的幾個領域？
在另一方面，建築非常的HQL微調查詢帶我回到老 經典ASP天，手工製作的SQL查詢...
任何最佳實踐建議？
謝謝大家，彼得。
我正在成爲Command/Query Separation（Greg Young版本）的堅定信徒，所以我想說如果你想向用戶顯示數據（Query），你絕對不應該使用你的域模型。當涉及到一個好的領域時，吸氣者往往是反模式。
我目前首選的過程是使用由NHibernate填充的屏幕特定的DTO。當從單獨的表中驅動時，這些工作效果最好，但是可以使用NHibernates AliasToBeanTransformer從域表填充。
嘗試一下，運行它，分析它。嘗試兩種方式，並使用像Red Gate's ANTS Profiler這樣的配置文件來查看是否存在明顯的性能差異。
如果沒有太大區別，那麼使用更易讀的版本 - 使用SportCenter類 - 否則使用HQL。
恕我直言，OR/Ms，在他們當前的狀態下，並不是完全替代SQL /變種。
+1規則優化：http://www.c2.com/cgi/wiki?RulesOfOptimization – 2009-09-01 16:29:22
順便說一句，我會推薦nhprof（http://nhprof.com/），而不是ANTS。 – 2009-09-01 16:29:56
如果您從BasketballField結束查詢，那麼每個BasketballField都可以「加入」SportCentre，或者從BasketballField結束時關閉延遲加載（因爲每個BasketballField只會有一個SportCentre）。
我所經歷的主要開銷來自nHibernate使用大量小型惰性負載對數據庫進行抖動，解決方案通常是讓它在一次往返中返回所有數據。
考慮Linq。 NHibernate支持Linq。使用Linq，編寫類型安全的查詢很容易，它可以返回「部分對象」或任何你想要的字段。
你提出的其他兩個選項可能是「夠好」，應該工作。
正如person-b所說，如果您關心性能，請使用分析器。
查看特定的DTO是最佳實踐，可能在此處有意義。
你的問題是你正在將你的域暴露給UI層。你應該將你的模型與ViewModel分開。
但是，屏幕特定的DTO使得業務層在UI層上感知和依賴（至少在語義上），這是不好的。即使只是爲了生成「視圖」而從nHibernate中寫出特定的查詢， 也會破壞僅nHibernate的數據訪問層。 無論如何，你的觀點聽起來很有動力，你的意思是什麼「吸氣者往往是一個反模式，當涉及到一個良好的領域」？ 謝謝你的回答，彼得。 – Peter 2009-09-01 20:49:12
實際上，你的DTO應該存在於一個單獨的查詢層中，其唯一的工作是滿足客戶端查詢的需要，在這種情況下，依賴關係是（非常好）。 業務層（或在我的情況下是域層）存在服務命令。 獲得者的問題是他們很快導致貧血域。如果每個人都可以獲得所有的數據（應該是私人的），那他們爲什麼需要你爲他們做任何事情？自從我在實用程序員中讀到「告訴，不要問」的原則以來，我一直在努力在我的設計中保留更多的面向對象。 – 2009-09-01 21:01:25