现在流行很多ORM工具,,使用的人群也非常多,而且大多都在说好,为什么呢?主要是使用简单,开发比较快速。然而，在项目开发中，为使你的项目更胜一筹，你就必须要合理的选择自己的开发工具。本文接下来将为你介绍几种常用的开发工具，希望对你的开发工作有所帮助。

　　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具有很强的可用性，但有时候往往会带来一些麻烦。