对 Ofbiz 中 Entity Engine 设计的探讨

OFBiz的entity engine和常见的ORM有一点很大不同,他mapping的object只有一个:GenericEntity,称它的entity engine为adaptive object model更为合适一些,是一种比较灵活,代码量非常少的独特的数据持久化方案。使用OFBiz的entity engine做的项目和其他ORM相比有一个很明显的特征就是:非常少的对象。

基于 Entity Engine 对数据库进行建模完全屏蔽了各种数据库的差别,使得 Ofbiz 可以支持从 MySQL 到 Oracle 几乎所有的关系数据库。但是这样设计有一个主要的问题就是性能。这个问题与以前 robbin 介绍的 PetStore 的 J2EE 实现相比 .Net 实现的劣势所遇到的一些问题是相同的。

http://forum.hibernate.org.cn/viewtopic.php?t=139&highlight=PetStore

以前我们在做 Ofbiz 开发时,一些简单的操作可以使用 Entity Engine 提供的 API 来做,但是复杂的操作(比如需要连接到多张表,当然出现大量低效率的连接多张表的情况是数据库设计的问题,但是这种情况还是很难避免)还是要使用低层的 API(相当于 BMP 吧)。这样就无法做到象 Hibernate 那样只要 JDBC 能做的 Hibernate 都能做了。由于我们现在做的业务都比较复杂(复杂的 OLTP 或者 OLAP),所以更希望使用一些比较低层的技术。

我的考虑,对于 Ofbiz 这样一种开源的产品,他们希望更多的人来使用并提出反馈意见。但是对于我们做项目来说,客户很少有中途更换数据库的可能(项目实施前已经确定使用 Oracle 还是 Sybase,etc.)。所以 Ofbiz 需要考虑的问题我们几乎不需要考虑。而性能是客户最关心的问题之一,如果你能用相同的硬件条件实现更好的性能,客户是非常欢迎的。

这是一个矛盾,更高层次的封装带来了灵活性和开发效率的提高,但是造成了性能的下降。PM 希望得到更快的开发效率,而客户还希望有更佳的性能。我使用 Ofbiz 的时候唯一的遗憾就是它的性能,其它方面 Ofbiz 的设计简直是美伦美幻,超出了我目前所能理解的限度。我只要能及老戴的一半,已经觉得很不错了。

从性能这方面来说,由于Hibernate是对于不同database做不同的dialect, 而OFBiz的entity engine则是面向JDBC通用api,性能肯定是比不上Hibernate等专业ORM。比如sequence no的生成,Hibernate有多种方式可以采用,可以直接利用数据库的特性(如自增长字段等),而EE采用的是Sequence Table,这样在大量create record操作的时候,就必然要慢很多。再比如说查询方面,Hibernate也可以利用数据库的特性做分页(如Oracle rownum,Mysql limit等),而EE只使用ResultSet定位。这样对于一些数据库来说,类似这样操作的性能不是在一个数量级上的。但是大多数情况下,2者的性能没有差很多,比如说一个应用系统中最常见的通过主键查找Object,最终生成的sql语句都是一样的,这样的操作性能都是相当的。

Cache 是提高性能的一个重要因素,Hibernate目前的Cache机制只能通过PK来缓存,EE则还提供了byAnd,byAll,这些Cache机制对于系统性能提高有非常明显的作用。

REF
http://dankes.spaces.live.com/blog/cns!FE25ED58CE9DD460!306.entry