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