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

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

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

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

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