目前我正在使用自定義業務對象層（採用外觀模式），其中從存儲過程加載對象的屬性以及爲業務邏輯提供位置。這一直在努力將我們的代碼基礎轉移到更分層和標準化的應用程序模型，但覺得這種方法更多是一個漸進的步驟，而不是一個永久的步驟。.Net ORM /業務對象框架性能
我目前正在研究轉向更正式的框架，以便某些架構決策不必是我自己的。在過去，我曾與CSLA和Linq合作過SQL，雖然我喜歡CLSA的許多設計決策，但我發現它對我的口味有點臃腫，Linq to SQL可能沒有我想要的性能。我對NHibernate的普及以及Linq對實體的推動感興趣，但是性能是一個關鍵問題，因爲有一些情況下需要一次提取大量記錄（> 15k）（請不要辯論原因爲此），並且對於採用正式的.Net對象框架看起來是最佳選擇的表現很好奇？
注意：這將主要用於Winform和WPF應用程序。
重複：https://stackoverflow.com/questions/146087/best-performing-orm-for-net
http://ormbattle.net - 那裏的性能測試看起來幾乎正是你想看到的。
你必須看看物化測試（獲取大量項目的性能正是它所顯示的）;而且，你可以將ORM性能與ADO.NET上幾乎理想的SQL性能進行比較。
太棒了！我甚至還在尋找更多的數據。謝謝！ – jwarzech 2009-12-15 14:51:55
隨着你打算通過在PROC緩存中的第1級得到提振開箱任何ORM。特別是對於負載，如果它已經存在，它不會去Pluto（DB）。大多數ORM有機會注入L2輸出緩存。關於這些的好處是他們只是插入ORM。爲NHibernate簽出NCache。
如果緩存使用率是_possible_，可能會有提升。但例如如果他從數據庫中順序讀取數以千計的非常簡單的對象，緩存將不會有多大幫助：ORM中的緩存顯着提高了隨機讀取的性能（實際上，通過簡單地減少ORM和RDBMS之間的差異），而不是順序讀取（因爲根本沒有討厭）。 – 2009-12-04 00:06:40
O/R映射器的性能將很大程度上取決於應用程序的設計方式以及映射業務對象的方式。例如，您可以輕鬆地通過在循環中延遲加載子對象來取消性能，以便1000個對象的1個選擇變爲1001個選擇（google n + 1 select）。
o/r映射器最大的性能提升之一是開發人員的生產力，這通常比應用程序性能更重要。對於大多數在最新硬件上運行的應用程序，最終用戶通常可以接受應用程序性能無論有多少Mountain Dew被應用到這個問題上，開發者的表現仍然是一個瓶頸。 :-)
聽起來好像你在問關於對象關係映射框架（簡稱ORM） - 你應該考慮改變你的問題的標題來指定，因爲很多人可能不會認同'對象框架'的含義。 – 2009-10-30 14:47:43
我想你正在尋找一個對象關係映射器（ORM），而不是「.Net對象框架」。您可能需要相應地更改標題... – 2009-10-30 14:47:46
感謝您的建議，我將其更改爲ORM /業務對象框架，因爲我不反對類似於CSLA的東西，它不是一個ORM。 – jwarzech 2009-10-30 14:54:37