實體框架4 vs NHibernate

Question

很多人已經在網絡上討論過Entity Framework的第一個版本（同樣在stackoverflow上），很明顯，當我們已經有了更好的選擇，比如NHibernate時，它不是一個好選擇。但我找不到實體框架4和NHibernate的比較。我們可以說今天NHibernate是所有.NET ORM中的領導者，但我們可以期望Entity Framework 4從這個位置取代NHibernate。我認爲，如果微軟真的在EF4中注入了非常好的功能，它可以給NHibernate帶來很好的競爭力，因爲它具有Visual Studio集成功能，更易於使用，並且在大多數商店中始終給予MS產品優先選擇權。

Answer 1

在「自我追蹤實體」中，EF4對於n層開發提供了一個現成的答案。沒有人發佈可比的NHib代碼。

NHib具有很多功能，這些功能都沒有被提及爲EF4的一部分。這些包括二級緩存集成。它在繼承映射方面具有更大的靈活性，與存儲過程/數據庫函數/自定義SQL /觸發器的更好集成，對公式屬性的支持等等。 IMO基本上只是作爲ORM更成熟。

Answer 2

我認爲EF 4將有能力使用POCO和延遲延遲加載的事實將是非常大的事實。我可以肯定地看到它在新版本中獲得牽引力。

Answer 3

這是事情。在我看來，NHibernate和實體框架真的適用於兩種不同的受衆。 NHibernate將是我構建一個具有複雜映射，公式和約束的系統（基本上任何企業）的選擇。如果我想通過簡單的數據訪問來運行，我會使用實體框架或LINQ-to-SQL。與EF相比，NHibernate沒有明確的「拖放」體驗。兩者都有其優點和缺點。坦率地說，比較他們的蘋果，蘋果，讓你無處可去。

Answer 4

我的2美分：我們在桌面客戶端上使用ef來進行一些cahing等 - 沒有高負載。 服務器端的NHib - 利用無狀態會話，hilo id生成和批處理。 以每秒db的速度插入3k +消息的速度非常快。它也非常靈活，支持很多dbs，這對我們的產品至關重要。

Answer 5

如果你認爲你可能曾經想要運行在Mono代碼，NHibernate的可能是一個更好的選擇，無論是功能清單說什麼......

編輯，2012年8月13日：

實體框架已經開源，現在包含在2.11.3版本的Mono中。現在這個答案已經過時，不應該依賴。

http://weblogs.asp.net/scottgu/archive/2012/07/19/entity-framework-and-open-source.aspx

Answer 6

更新：我自4.0版本沒有使用實體框架，所以我的答案可能是過時的。我仍然在我的項目中使用NH或純ADO .NET。自從4.0以來，我甚至不想看看EF的新功能，因爲NH完美地工作。

實際上很容易比較它們，當你使用兩者。有與EF4一些嚴重的限制，我可以說出一些我遇到我的自我：

EF4問題：

• 預先加載和塑造的結果：EF4渴望裝載系統（包括（「路徑「））會產生不正確的SQL，並帶有循環JOIN，這會對多對多關係執行數千次（而不是字面上的）時間，然後手寫SQL（它實際上無法使用）。
• 物化器無法實現關聯的實體：如果您認爲可以通過提供自己的SQL查詢來克服以前的問題，那麼您就錯了。 EF4無法從JOIN SQL查詢實現（映射）關聯實體，它只能從一個表中加載數據（因此，如果您有Order.Product，則SELECT * FROM order LEFT JOIN Product將僅初始化Order對象，Product將保留爲null，認爲在查詢中獲取所有必要的數據以初始化它）。這可以通過使用EFExtensions社區插件來克服，但您必須爲此編寫的代碼非常難看（我嘗試過）。

• 自我跟蹤實體：許多人認爲自我跟蹤實體對於N層開發很酷，包括本主題中的頂級答案。以爲我甚至沒有給他們一個嘗試，我可以說他們不是。每個輸入都可以僞造，你不能簡單地將用戶發送給你的改變應用到數據庫，爲什麼不給用戶直接數據基地訪問呢？任何你將不得不加載數據的用戶都將從數據庫中進行更改，檢查它是否存在|不存在執行權限檢查等等。你無法相信用戶對他發送給服務器的實體的狀態，反正必須從數據庫加載這個實體並確定它的狀態和其他事情，因此這些信息是無用的，自我跟蹤實體也是如此，除非您爲內部使用建立私有的可信的n層系統，在這種情況下，您可能只是簡單地數據庫訪問。 （這就是我對ST實體和N-輪胎的想法，我不是很在N層expericned，所以它可以改變，如果我誤解的東西在這裏評論吧）

• 記錄，活動，整合的商業邏輯： EF4就像是黑盒子，它做了一些事情，你不知道它做了什麼。只有一個事件OnSavingChanges，您可以在DB發生某些事情之前放置一些您需要運行的業務邏輯，並且如果您在發生某些事情之前需要對業務對象進行一些更改，則必須在ObjectStateManager中進行挖掘，這真的很難看，代碼可能會變得巨大。例如，如果您使用Repository模式以及以乾淨對象的方式對DB進行的更改進行通知，您將很難用EF做這件事。

• 可擴展性：所有EF代碼是私有的，內部的，如果你不喜歡的東西（你會不會想了很多，如果你是認真的EF使用），沒有辦法，你將簡單的方式改變這種實際上，我確信從頭開始編寫自己的ORM（我做過）會很容易，然後根據需要讓EF工作。舉例來看EFExtensions源代碼，它基於擴展方法，以及不同的「黑客」來使EF更有用，代​​碼非常難看（而且這不是作者的錯誤，當EF中的所有內容都是私有的，這是唯一的方式來擴展它）。

我可以繼續寫關於EF的不好的事情，以及對於我來說這是多麼痛苦的20頁，也許我會。

NHibernate怎麼樣？這是完全不同的級別，它就像比較PHP和C＃，EF4就像在Stone-age中一樣，這就像EF在開發過程中比NHibernate落後了10年，事實上，Hibernate是在2001年開始的。如果你有空有時間學習並打開Nhibernate，就這樣做。

Answer 7

我認爲這是因爲EF4.0自1.0以來已經走過了很長的一段路，並且正在趕上Nhibernate的功能，但它還不是全部。

但是，它是開箱即用的微軟，它完成了95％的應用程序所需要的功能。但是，NHibernate多年來一直在做同樣的事情。到5.0或6.0版本可能趕上，甚至超過NHibernate。

這是我的建議 - 如果你有時間去學習，那就去做吧。有幾個理由選擇一個。如果你正在爲一家公司編寫代碼，期望能夠熟練使用EF的員工是現實的，因爲它是所有書籍和孩子在大學學習的內容。如果EF能夠滿足你的要求（在說出是的話之前想想這個很長很難），那麼現在它是一個完美的解決方案，並且在幾年內它可能（很可能會超越NHibernate）。

NHibernate是一個非常成熟的產品，幾年在EF上，很可能會做你想做的一切，然後一些。一段時間以來，它一直是最好的ORM，很多人都使用它。

Answer 8

用邏輯層的Linq組合直接映射到存儲過程似乎是最簡單的方法。沒有xml。僅爲不常用或不適用於存儲過程的有趣查詢生成sql。

對象通過標準SP加載和存儲。這種方法允許使用兩個SQL登錄名。一個用於通過SP（僅執行權限）訪問類，另一個用於允許直接訪問表的邏輯LINQ模塊。

Answer 9

有一個明顯的trend增加EF熱門NHibernate，看到圖片。

Answer 10

人氣ORM的之間進行選擇是不是做的最好的事情。 我已經嘗試過過去2年轉向EF，我只能說，爲什麼我仍然嘗試着呢？

ATM我對EF的觀點是：「它是爲小型非常小的系統製造的，不超過3個表，關係少於1（0更好）」。

爲什麼我會那樣想？ 1.嘗試更新未連接的圖形並查看模型劃痕;

1. 儘量讓TPH深繼承樹，你會發現你，你是schackled到一個層次或系統將打破。

2. 試着做出更麻煩的查詢，並觀察整個系統吃掉堆棧：D ...溢出發生的頻率很高。

3. 映射XML數據類型基於擴展或最討厭的NotMapped屬性......它更糟糕。

4. 嘗試將SQL查詢混合到Linq以獲取更多finner查詢，並且您將打破牆上的大聲笑。而且最後也是最重要的一點是，EF不支持屬性公式（'對於遺留數據庫來說NH是一個很棒的資源'），並且不支持同一表和相關表的複雜類型映射。

這是我的10cc。