2009-08-07 35 views
3

我基本上想知道的東西,如:實體框架2和NHibernate如何比較?

  • 兩者之間的優缺點?
  • 這兩個框架的相似之處?
  • 它們在建築上的相似/不同?
  • 需要多少樣板代碼才能使用它們?
  • 與NHibernate相比,實體框架可以在Visual Studio之外高效使用嗎?與Visual Studio一起使用時,實體框架比NHibernate更有效嗎?

注:此問題涉及實體框架2(目前仍在開發中)。

+0

[我是否應該使用實體框架4.0?](http://izlooite.blogspot.com/2011/04/should-i-ever-use-entity-framework-40.html) – 2011-04-23 15:31:48

回答

8

免責聲明:這篇文章是基於我目前的實體框架的下一個版本將是什麼樣的知識。這可能是不準確的,或者可能會改變,直到下一個版本實際上被轉移。

一般方法:

實體框架(EF)的主要方法是使用自己的圖形設計工具來創建一個實體數據模型,並從該模型生成域類以及映射。還有其他方法的支持,但這種工作方式可能永遠是主要方式。 (NH)是一個基於文本的工具,它需要用戶手動編寫所有的域類和映射,如果你不轉向用於代碼生成的第三方軟件,比如CodeSmith的MyGeneration或其他約定通過配置支持,比如Fluent NHibernate。

代碼生成:

代碼生成標準EF使用的主要部分,或者通過使用他們的圖形設計工具或使用他們的命令行工具。 GUI和命令行工具的可用性是一個優點,因爲使EF易於入門,並允許更高級的使用,例如在構建過程中可以實現自動化。如果要計算爲代碼生成

代碼生成不被支持的NHibernate,除了架構生成的東西。如果你轉向第三方軟件,你可以獲得代碼生成。

數據庫架構生成:

EF將增加對模型首先開發的支持,允許用戶生成從實體數據模型架構。 NHibernate已經有很長一段時間的模式生成支持。如前所述,這裏的區別在於如何創建「模型」。

LINQ:LINQ的

EF將有所改善,從V1和NH其怪誕的LINQ實現現在已經達到了1.0版NH,所以不應該有這方面的任何兩者之間的主要區別。

POCO:

EF將增加的領域驅動設計方法和使用從數據訪問層分離領域類的更好的支持。但是,由於POCO不是EF的主要用例,我不能真正看到他們的POCO支持如何達到NHibernate的水平。 EF中的POCO支持還很年輕,對我而言,如果您是POCO/DDD支持者,並且因爲某些原因而發現自己在EF上工作,那麼感覺更像是一種獎勵。

整個NHibernate框架是由DDD人員爲POCO開發構建的,他們已經達到了2.1版本,並利用了Java端的所有工作。相當長一段時間內,NHibernate可能仍然是DDD/POCO/ALT.NET人羣的首選。

延遲加載:

EF的下一個版本將包括自動延遲加載的支持。自動延遲加載一直是NHibernate很長一段時間的重要組成部分。

學習曲線:

兩個框架是複雜和強大,因此需要很長的時間才能掌握。但EF對初學者非常友好,因爲它通過其圖形設計工具集成到Visual Studio中,並且因爲它可以爲您生成很多東西,而不必知道關於框架的任何內容。但是,如果您想深入瞭解EF並真正瞭解該框架,則應該準備花費大量時間使用它。 NHibernate有一個臭名昭着的學習曲線,但最近的一些改進已經減少了一點。現在,LINQ to NH在v1.0,查詢語法對於新開發NH的開發人員來說更容易理解,而Fluent NHibernate項目正在改進映射體驗,甚至在自動映射上工作,自動映射越來越好,所有時間。

+2

這是一個很好的答案(+1),但我不同意LINQ。儘管可以*不使用LINQ來使用EF,但我不知道有誰已經完成了它。在EF中,你將生活和呼吸LINQ。在NH,OTOH中,大多數用戶不使用LINQ,而新發布的LINQ to NH非常有限(在作品中有一個較少限制和*完全獨立的*實現)。此外,EF基於持久性/運輸價值對象(包括ORM和數據服務方面)的思想而構建,而NH則是一個更「傳統」的ORM。 – 2009-08-07 12:57:34