一個在ADONET實體框架（Entity FrameworkEF）項目中的微軟開發人員Danny Simmons他最近發表了一個對實體框架和其他數據訪問解決方案比較的博客帖子在和傳統的ADONET及LINQ to SQL比較之後Danny又把實體框架和nHibernate進行比較這就引起了其他開發人員的反對下面是Danny的帖子的摘錄
在EF和nHibernate之間最大的不同是實體數據模型（Entity Data ModelEDM）以及我們基於這個東西構建的需要長久運行的數據平台EF通過了特別的構造將查詢/形成結果的映射過程與構建對象和變更跟蹤分離開來這種方式讓創建概念模型變得更為容易而概念模型使你可以考慮如何實現數據以便隨後能在其他很多包含了這些構建對象的服務中重用長期以來我們把EDM這樣的思想融入到多個其他微軟產品中以至於假如你擁有一個實體數據模型你可以基於這個模型自動創建面向REST的Web Service（ADONET Data Service即Astoria）可以基於這個模型編寫報表（Reporting Services）可以在服務器和脫機客戶端存儲庫中同步數據這些數據可以作為實體進行原子性地移動就算這些實體是從服務器上的多個數據庫表中抽取而來可以從實體感知的構建部件中創建工作流等等等等……所以所謂的不同點不是EF比Nhibernate能支持更復雜的映射功能或其他類似的東西而是在於——EF不僅僅是一個ORM它是在基於實體理念的數據平台中龐大願景中的第一步
作為回應Frans BoumaLLBLGen Pro的主創人員一個微軟MVP在它的帖子中寫到
我不同意這種說法一個像Danny Simmons這樣工作於實體框架中如此久的人這樣的人怎麼能忽略這樣一個事實——任何O/R Mapper都是針對實體理念的在他最後一句話中所描述的東西實際上是一個單一目的的O/R Mapper就是讓開發人員能在OO語言中使用實體實例並把這些實例保存到如關系數據庫這樣的非OO環境中反之亦然假如所有的東西就是抽象的實體模型和它的投射那麼更大的願景是什麼呢？也許工具？它讓開發人員創建這些投射和在應用程序代碼中調用O/R Mapper服務根據容易
Jeremy D Miller一個NET開發人員和構架師在他的博客中說到Danny Simmons
他在比較NHibernate和實體框架過程中遺漏了一個重要的事實實體框架對你的應用程序具有很強的入侵性而Nhibernate沒有NHibernate讓我能使用POCO的方式來對業務過程進行建模而無需知曉數據庫而實體框架卻要我把EF的基礎結構直接加入到我的業務對象中
Danny Simmons提到的為其他目的（如報表）而使用EDM的好處Greg Young——一個微軟的MVP在他的博客上對其進行了評論
一個單一的模型不可能適應你的應用程序裡包括事務行為搜索和報表在內的所有方面……可以舉出很多這樣的內容來如果你基於你的事務模型來創建報表那麼你就會遇到麻煩！
Jimmy Bogard一個Headspring Systems的高級顧問也在他的博客中回應到
我認為把數據模型共享給你邊界外的任何人是錯誤的（參看EvansDomainDriven Design）把概念模型或EDM或其它我們以任何名字稱呼它的東西共享出來也是錯誤的
我從來不把域對象直接通過服務暴露出來這是對我盡量創建的封裝的一種侵害
如果任何人想要一個SSRS【譯者注SQL Server Reporting Service】那麼我會給他們一個單獨的報表數據庫——為報表所需而定制的我不希望報表的關注點影響了我們的事務關注點一個映射層不能解決這樣的問題但類似SSIS【譯者注SQL Server Integration Service】這樣的產品卻可以你想要報表？好這裡有你需要的只讀視圖每小時分鐘每天或隨時進行更新
所以現在的問題是ADONET實體框架是否已經不僅僅是一個O/R Mapper了以及它如何和nHibernate進行比較？很多人傾向於認為EF是一個簡單的O/R Mapper並認為它相對於nHibernate而言缺乏很多特性另外一方面Danny Simmons說微軟剛剛開始開發EF他們的計劃是未來要超越當前的O/R映射功能
From:http://tw.wingwit.com/Article/program/net/201311/14791.html
