小评几种O/R Mapping工具

LLBLGen Pro 
满意度:
撞头度:
      作为一个商业组件,可以说它是一个令我不知所措的一个工具,它提供的功能超出了我的想象,犹其在易用性上,提供了一个非常漂亮的界面,可以很自由的制作出表然后直接生成业务层的代码,这一点是非常不错的。它支持Oracle、IBMDB2、Firebird、MySql、SqlServer、Access这几种数据库,基本上还是够用了的。
     它最大的特色在于对数据库的存储过程的支持,这一点是非常让人兴奋的,毕竟尽管不少架构师都认为存储过程造成了数据库移植的难度,但要做高性能的数据库应用程序,存储过程是一个首选方案,比如插入一张图片的二进制数据到数据库中时,存储过程无论如何都要比直接写个Sql语句要快得多,同时,在具体进行开发分工时,对于前台与后台的分工上显得也比较明确,更能够有效地利用人力资源。
  它能够直接生成基于vs.NET2003的解决方案,对中文的支持也非常不错,但可惜的,它提供的数据库表的浏览器并不支持直接编辑,同时也没有关系视图的表示,这样的话,实际上它显示UI界面的意义并非十分重要,最终的数据库设计还是得依赖于对数据库的直接操作。换而言之,它仅是一个由表到实体类的代码生成器,虽然看似灵活,实际上在真正的实际操作中,需要自己的更改代码的部分还是比较多的,这对于一个称之为O/RMapping的工具来说,是一个不够完善的地方。

NHibernate 
满意度:
撞头度:
  作为从Java世界中移植而来的工具而言,Hibernate的成功是有目共睹的,然而这并不意味着NHibernate的成功,尽管听说有参与了Hibernate开发的人员加入了NHibernate阵营,但这并非表示事情很乐观。如果NHibernate能够在今年6月份前发布1.0的release的话,那么还可以满足一下大众的需要,但根据目前的进度估计及目前NHibernate的相关资料分析,6月份前要发布一个较为理想的版本,难度还十分之大。
  从严格意义上来说,NHibernate是相对于其它的O/R Mapping组件拥有更成熟的思想与构架,而且有着Hibernate的皇族血统,这对于.NET平台下的开发的意味是非常巨大的。NHibernate在灵活性上也具有其它组件不可比拟的优势,但可惜的是,毕竟NHibernateJava血统过浓,移植的可靠性还需要一段时间来进行检验,同时对于企业级的应用,我相信追求稳定性的大多数人更宁愿肯选择微软的解决方案(就算微软的解决方案并不理想)。而且,它的发布实在是太慢了,如果等到微软的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与SqlServer。作为一个商业组件,Devexpress公司提供了完整的源码,用户可以自由地与源码进行修改和变化。XPO中的数据库对象是从MashalByObject继承而来的,可以继承用的基类比较灵活,可以选择是要由系统来自动生成主键,还是通过代码自定义主键,或者全部都手工定义。
  XPO.NET在特性上比较平平,没有什么很耀眼的地方,感觉上比较朴素,也很稳定,不少人都使用了XPO作为自己的数据层构造的首选。它与Gentle.NET一样,都是利用特性映射来自动生成数据库及其中的表,使用上还算方便。
  虽然如此,但XPO.NET有一些让人用起来很不爽的地方,首先,几乎没有XPO的代码生成器(虽然我写了一个,但因为XPO本身特性的原因,受到的限制非常多),开发者需要费大量的时间去构建一张表或者是其它什么东西,感觉仿佛回到了写SQL创建数据库与表的时代。其次,它强调由代码到数据库,重心非常明显,如果尝试做一个由表到XPO的代码生成器的话,会发现,一般情况下,对于原有的数据库结构都是很有必要进行调整的,也就是说,XPO.NET没有过多地考虑映射已存在的数据库结构的能力(虽然它看起来好像提供了支持,但你如果知道主键必须是int或uniqueidentifier中的一种的话,你就不会这样想了)。
  作为一个O/R Mapping组件,XPO.NET具有很强的可用性,但有时候往往会带来一些麻烦。

it知识库小评几种O/R Mapping工具,转载需保留来源!

郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。