LLBLGen Pro　
滿意度：
撞頭度：
      作為一個(gè)商業(yè)組件，可以說它是一個(gè)令我不知所措的一個(gè)工具，它提供的功能超出了我的想象，猶其在易用性上，提供了一個(gè)非常漂亮的界面，可以很自由的制作出表然后直接生成業(yè)務(wù)層的代碼，這一點(diǎn)是非常不錯(cuò)的。它支持Oracle、IBMDB2、Firebird、MySql、SqlServer、Access這幾種數(shù)據(jù)庫，基本上還是夠用了的。
     它最大的特色在于對(duì)數(shù)據(jù)庫的存儲(chǔ)過程的支持，這一點(diǎn)是非常讓人興奮的，畢竟盡管不少架構(gòu)師都認(rèn)為存儲(chǔ)過程造成了數(shù)據(jù)庫移植的難度，但要做高性能的數(shù)據(jù)庫應(yīng)用程序，存儲(chǔ)過程是一個(gè)首選方案，比如插入一張圖片的二進(jìn)制數(shù)據(jù)到數(shù)據(jù)庫中時(shí)，存儲(chǔ)過程無論如何都要比直接寫個(gè)Sql語句要快得多，同時(shí)，在具體進(jìn)行開發(fā)分工時(shí)，對(duì)于前臺(tái)與后臺(tái)的分工上顯得也比較明確，更能夠有效地利用人力資源。
　　它能夠直接生成基于vs.NET2003的解決方案，對(duì)中文的支持也非常不錯(cuò)，但可惜的，它提供的數(shù)據(jù)庫表的瀏覽器并不支持直接編輯，同時(shí)也沒有關(guān)系視圖的表示，這樣的話，實(shí)際上它顯示UI界面的意義并非十分重要，最終的數(shù)據(jù)庫設(shè)計(jì)還是得依賴于對(duì)數(shù)據(jù)庫的直接操作。換而言之，它僅是一個(gè)由表到實(shí)體類的代碼生成器，雖然看似靈活，實(shí)際上在真正的實(shí)際操作中，需要自己的更改代碼的部分還是比較多的，這對(duì)于一個(gè)稱之為O/RMapping的工具來說，是一個(gè)不夠完善的地方。

NHibernate　
滿意度：
撞頭度：
　　作為從Java世界中移植而來的工具而言，Hibernate的成功是有目共睹的，然而這并不意味著NHibernate的成功，盡管聽說有參與了Hibernate開發(fā)的人員加入了NHibernate陣營，但這并非表示事情很樂觀。如果NHibernate能夠在今年6月份前發(fā)布1.0的release的話，那么還可以滿足一下大眾的需要，但根據(jù)目前的進(jìn)度估計(jì)及目前NHibernate的相關(guān)資料分析，6月份前要發(fā)布一個(gè)較為理想的版本，難度還十分之大。
　　從嚴(yán)格意義上來說，NHibernate是相對(duì)于其它的O/R Mapping組件擁有更成熟的思想與構(gòu)架，而且有著Hibernate的皇族血統(tǒng)，這對(duì)于.NET平臺(tái)下的開發(fā)的意味是非常巨大的。NHibernate在靈活性上也具有其它組件不可比擬的優(yōu)勢，但可惜的是，畢竟NHibernate的Java血統(tǒng)過濃，移植的可靠性還需要一段時(shí)間來進(jìn)行檢驗(yàn)，同時(shí)對(duì)于企業(yè)級(jí)的應(yīng)用，我相信追求穩(wěn)定性的大多數(shù)人更寧愿肯選擇微軟的解決方案（就算微軟的解決方案并不理想）。而且，它的發(fā)布實(shí)在是太慢了，如果等到微軟的vs.NET2005推出后再發(fā)布的ObjectSpace組件正式release了的話，NHibernate的前景就比較難料(畢竟我們還不知道正式release的ObjectSpace會(huì)長成什么模樣）
　　不過，根據(jù)世界范圍來看，NHibernate的關(guān)注人群非常之多，它是一個(gè)在.NET下倍受關(guān)注和推崇的項(xiàng)目，在遠(yuǎn)景規(guī)劃上有現(xiàn)成的方案可以參考，還有一點(diǎn)重要的是，以微軟的作風(fēng)，ObjectSpace應(yīng)該不會(huì)提供多種類數(shù)據(jù)庫的支持，然而這對(duì)于許多開發(fā)人員來是，卻是非常重要重要的，所以從一定意義上來說，NHibernate在一段時(shí)間內(nèi)的發(fā)展將會(huì)是樂觀的。

EntityBroker
滿意度：
撞頭度：
　　這又是一個(gè)商業(yè)組件，商業(yè)組件在構(gòu)架上未必比開源的項(xiàng)目更好，但商業(yè)組件有一個(gè)好的地方在于有良好的技術(shù)支持與售后服務(wù)，用起來比較放心，不必像開源組件那樣必須等到下一個(gè)版本的release。
　　EntityBroker 是一個(gè)相對(duì)比較好的組件，它的特色在于對(duì)COM+ 事務(wù)的支持，這一點(diǎn)是大多數(shù)O/R Mapping組件沒有做到的。不過，對(duì)于習(xí)慣了數(shù)據(jù)綁定的開發(fā)人員來說，使用EntityBroker 并不是一個(gè)好的選擇，它在這方面的支持可謂是惡劣。它有一個(gè)現(xiàn)象就是查詢一個(gè)對(duì)象時(shí)，效率非常之高，但如果你想一次性弄出一堆對(duì)象來的話，效率就會(huì)很低下。尤其是進(jìn)行諸如DataGrid的綁定的時(shí)候，數(shù)據(jù)量一大，其效率很難令人難受。這可能是由于EntityBroker 在查詢機(jī)制上過分強(qiáng)調(diào)了功能的緣故。
　　我個(gè)不太喜歡這玩意，不過它的好評(píng)卻是不可忽視的。

Gentle.NET
滿意度：
撞頭度：
      作為.NET開源世界中的一分子，Gentle.NET也是一個(gè)比較不錯(cuò)的組件，雖然相對(duì)于NHibernate來說，它出現(xiàn)得太遲了一些，但它提供了一系列不可忽視的特點(diǎn)，并且比NHibernate更早地進(jìn)行了1.0版本的release，從它的版本歷史上來看，更新頻率是非常快的。
　　根據(jù)Gentle.NET的測試文檔分析，它已經(jīng)達(dá)到了可以滿足一般性的需要的目的，尤其它對(duì)數(shù)據(jù)庫種類的支持，包括了Firebird、Jet、MySQL、Oracle、PostgreSQL、SQLite、SQLServer、SQLServerCE、Sybase，可以說這是令人非常興奮的，這意味著在數(shù)據(jù)庫間的代碼移植難度被大大地降低了。另
　　從國內(nèi)的情況看來，Gentle.NET的資料非常少，研究它的人似乎也并不多。甚至在Gentle.NET自己的文檔方面，也令人很不滿意，沒有提供一個(gè)使用該組件的良好指導(dǎo)，僅僅是提供一個(gè)測試驅(qū)動(dòng)的項(xiàng)目，使用者要清楚具體的用法，不得不自己去揣摩。不過，如果研究過持久化設(shè)計(jì)的人，使用這個(gè)組件倒是非常順手的，因?yàn)樗cNHibernate一樣，是基于魯棒性的持久化設(shè)計(jì)的。
       Gentle.NET是基于特性映射的，這與NHibernate有著極大的不同：從一般的應(yīng)用級(jí)別開發(fā)而言，特性映射是完全夠了的，但對(duì)于企業(yè)級(jí)較大一些的應(yīng)用來說，特性映射是遠(yuǎn)遠(yuǎn)不夠的。因?yàn)閺?fù)雜的映射過程需要一個(gè)集中管理的界面來進(jìn)行反映，而Gentle.NET目前采用的特性映射的方式，很顯然在集中管理上并無法起到有力的支持，如果數(shù)據(jù)庫表中的字段有部分更改，Gentle.NET的魯棒性就會(huì)受到挑戰(zhàn)，這個(gè)挑戰(zhàn)不是來自于功能上的，而是來自于管理上的，代碼生成器由于生成過程的直觀性與框架是一樣的差，所以即使有MyGeneration這種工具，Gentle.NET也無法避免字段帶來的種種問題。

XPO.NET
滿意度：
撞頭度：
　　作為Devexpress公司出品的產(chǎn)品，它一出世就倍受大家的關(guān)注，就應(yīng)用上而言，也是非常廣泛的。XPO支持的數(shù)據(jù)庫種類很少，僅僅是Access與SqlServer。作為一個(gè)商業(yè)組件，Devexpress公司提供了完整的源碼，用戶可以自由地與源碼進(jìn)行修改和變化。XPO中的數(shù)據(jù)庫對(duì)象是從MashalByObject繼承而來的，可以繼承用的基類比較靈活，可以選擇是要由系統(tǒng)來自動(dòng)生成主鍵，還是通過代碼自定義主鍵，或者全部都手工定義。
　　XPO.NET在特性上比較平平，沒有什么很耀眼的地方，感覺上比較樸素，也很穩(wěn)定，不少人都使用了XPO作為自己的數(shù)據(jù)層構(gòu)造的首選。它與Gentle.NET一樣，都是利用特性映射來自動(dòng)生成數(shù)據(jù)庫及其中的表，使用上還算方便。
　　雖然如此，但XPO.NET有一些讓人用起來很不爽的地方，首先，幾乎沒有XPO的代碼生成器（雖然我寫了一個(gè)，但因?yàn)閄PO本身特性的原因，受到的限制非常多），開發(fā)者需要費(fèi)大量的時(shí)間去構(gòu)建一張表或者是其它什么東西，感覺仿佛回到了寫SQL創(chuàng)建數(shù)據(jù)庫與表的時(shí)代。其次，它強(qiáng)調(diào)由代碼到數(shù)據(jù)庫，重心非常明顯，如果嘗試做一個(gè)由表到XPO的代碼生成器的話，會(huì)發(fā)現(xiàn)，一般情況下，對(duì)于原有的數(shù)據(jù)庫結(jié)構(gòu)都是很有必要進(jìn)行調(diào)整的，也就是說，XPO.NET沒有過多地考慮映射已存在的數(shù)據(jù)庫結(jié)構(gòu)的能力（雖然它看起來好像提供了支持，但你如果知道主鍵必須是int或uniqueidentifier中的一種的話，你就不會(huì)這樣想了）。
　　作為一個(gè)O/R Mapping組件，XPO.NET具有很強(qiáng)的可用性，但有時(shí)候往往會(huì)帶來一些麻煩。

it知識(shí)庫：小評(píng)幾種O/R Mapping工具，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。