我期待在我們的系統中實現一個ORM。我們目前有許多包含大量可怕數據和存儲過程的表格。我聽說使用ORM會降低系統速度。有誰知道使用C＃代碼中創建的查詢和映射到存儲過程的哪個ORM在速度和性能上更好？實體框架vs NHibernate - 性能
感謝
編輯：
該項目將使用大現有的表，幷包含大量的數據，它也將使用在SQL Server數據庫進行復雜的任務，現有的存儲過程。在運行現有存儲過程並查詢當前表時，ORM必須能夠執行事務並具有高性能。該項目是基於Web的，將使用WCF Web服務和DDD。我可以看到EF使用起來更容易，並且有更多的支持，但是如果NH是最合適的選擇？
實體框架不斷實現新功能，並且您的項目中的所有內容都是自動執行的。使用Entity Framework非常簡單，可以擴展和重構代碼。 Visual Studio整合了它（代碼優先，數據庫優先，實體優先...），就像魅力一樣。 Windows Azure可以輕鬆部署和更改它。另外，Visual Studio可以在3次點擊中生成所有的CRUD頁面。
我建議你使用EF，但它取決於你的項目。你能給我們更多關於它的細節嗎？
您可以在Google上找到大量比較圖表，例如this one解釋性能和this one差異。
編輯：
你可以量化在應用程序的用戶數量？
當您在EntityFramework中使用Database-First時，對於NHibernate而言，它非常容易到import and use stored procedures，它也是如此。 請注意，如果您使用大量存儲過程而不是很多併發用戶，那麼在這兩者之間選擇ORM可能不那麼重要。
另外不要忘記，一個工具的性能往往是基於使用它的方式。如果您誤用了ORM（例如異步，懶惰/渴望加載，基類等），則性能將急劇下降。
也許你可以安裝他們兩個，看他們是如何工作的，並檢查他們的路線圖（例如Entity framework）以檢查進化和興趣。
流利的NHibernate不需要創建映射文件！ – danyolgiax
的確，感謝您發現這一點，我正在開發舊項目，並且在此日期，Fluent NHibernate不存在，所以我必須手動創建映射。 – glautrou
嗨，請看我編輯的項目詳情，謝謝 – Funky
兩者都是很好的解決方案，但我個人認爲NHibernate更適合繼承數據庫。這裏是一個很好的功能明智的比較 -
http://www.dennisdoomen.net/2013/03/entity-framework-56-vs-nhibernate-3.html
有一些事情是在NHibernate的明顯更好，比如二級緩存支持。文檔可能比EF稍微稀疏，但如果你願意通過學習曲線，NHibernate爲你提供了更多的功能。
FluentNHibernate非常適合將類型映射到底層表，但是有些地方您只需要恢復到XML映射。 NHibernate本身有一個新的競爭API，但我還沒有檢查它（上面的博客文章提到它）。
如果你想依靠VS工具支持，EF更好。然而，有時候會有一些魔法（例如，EF可以使用反射來填充對象的私有屬性，NHibernate不會這樣做;這取決於您如何看待它的優點或缺點）。 EF也適用於其他Microsoft提供的框架（例如RIA服務）。我也喜歡EF-auto遷移（當你使用代碼優先）。如果你想要更多的權力在你手中，並希望能夠調整事物的工作方式並明確區分顧慮（ORM只做ORM應該做的事情），NH似乎更好。然而，讓NH能夠訪問它們的所有屬性是有點令人煩惱的。
我已經使用它們，有時可能會有點笨重有時生成你想要的SQL;在這些5-10％的情況下，再下降一級並使用像Dapper，Massive或Petapoco這樣的微型企業。
編輯：
NHibernate的太能填充私人性質，貌似，所以這是我的一部分只是無知。
.NET 4.5上的EF 5或6是提高性能的一種可靠方法，不要指望.NET 4.0上的EF 5有任何速度提升，這是由Microsoft記錄的。 （我們還有另一個寫得不好的LINQ語句的問題）。
一般來說，如果性能高優先級，則無法使用存儲過程擊敗ADO.NET。你根本做不到。添加了ORM，添加了IOC容器......您想要對性能進行多少測試？
用JMETER調出一些虛擬機，然後用EF打出一個服務器，然後用NHibernate重啓另一個虛擬機，你只需強制JMETER調用URLS並測試併發用戶的數量，並且你應該看到你的瓶頸在哪裏。
對於簡單的select語句，存儲過程沒有更多優勢，因爲所有現代DBMS都記住正確參數化的SQL查詢，並使用相同的查詢計劃執行它們，如存儲過程。如果需要過程元素，例如循環，控制元素，變量等，存儲過程是很好的。 –
簡單的select語句究竟是什麼。 「從simpleTable中選擇simple1，simple2」？那麼，如果這張桌子有1000萬行呢？根據定義，這是一個「簡單的選擇語句」，但後端表格翻轉巨大，那麼通常最好放置一個proc。我喜歡linq語句，但是用linq語句代替sprocs的所有人都沒有證明這是明智的。許多網站正在爬行，需要付出很多努力才能解決問題。 –
視圖比數據訪問的價格更好。然後，您在視圖上使用ef，仍然可以獲得組合性。 –
這裏值得一提的是Entity Framework在連接斷開連接的圖時存在問題，並且在Nhibernate中缺少合併功能。您可以使用其他插件解決此問題，但不能立即投入使用。這是Codeplex上的功能link，要求更好地支持斷開實體的工作，並且還有一些進一步的討論。
EF中缺乏.Merge是一些交易斷路器。 OP應該研究這一點。 「實體框架合併」。谷歌或Bing它。你會看到那個大snap。。 – granadaCoder
check this artical 在EF一些NH的優勢
多大的項目是我們說？幾百個查詢，幾千？你是否優先搶先？沒有什麼事情會像直接查詢一樣快，或者像Dapper.NET那樣快，但依賴於代碼的使用方式仍然可以合理使用。 –
[Entity Framework 4 vs NHibernate]可能的重複（http://stackoverflow.com/questions/1639043/entity-framework-4-vs-nhibernate） – Paddy
看看下面的內容：http://stackoverflow.com/問題/ 699792/is-orm-slow-it-matter –