浏览 10343 次
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2003-11-09
Quake Wang 写道 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 的设计简直是美伦美幻,超出了我目前所能理解的限度。我只要能及老戴的一半,已经觉得很不错了。 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2003-11-09
要是ofbiz以后象新avalon一样,支持持久层自己选择,就不是更好了
|
|
返回顶楼 | |
发表时间:2003-11-09
晕,下载了一个ofbiz,别说看源码了,连装上都难……
其实关于性能问题,关键还是要发挥数据库的专有特性。DAO可以帮我们分开业务逻辑和存取逻辑,由于经验所限,我目前所用过的数据库专有特性不过是视图、存储过程和游标这几个基本特性,这些用基本的JDBC就可以了。在更复杂的应用中还有哪些东东呢?要用到什么API呢? |
|
返回顶楼 | |
发表时间:2003-11-09
无明 写道 晕,下载了一个ofbiz,别说看源码了,连装上都难……
别急,先看一下文档,Ofbiz 的文档写得还是比较好的。 我好久没有研究 Ofbiz 了,有空了还是要拾起来的。 |
|
返回顶楼 | |
发表时间:2003-11-09
从性能这方面来说,由于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机制对于系统性能提高有非常明显的作用。 dlee 写道 以前我们在做 Ofbiz 开发时,一些简单的操作可以使用 Entity Engine 提供的 API 来做,但是复杂的操作(比如需要连接到多张表,当然出现大量低效率的连接多张表的情况是数据库设计的问题,但是这种情况还是很难避免)还是要使用低层的 API(相当于 BMP 吧)。这样就无法做到象 Hibernate 那样只要 JDBC 能做的 Hibernate 都能做了。
不知道你以前做开发用的OFBiz的版本是多少,早期的版本在对于数据库的复杂操作上支持得不是很好,在2.0以后,直至最新的CVS 3.0版本上,对于这一块一直有在提高,虽然不能说JDBC能做的EE都能做,至少95% JDBC能做的,现在EE都能做了。 btw, 做复杂的OLTP专案,如果数据库已经选定,对于性能有非常高的要求的关键模块,最佳方法就是store proc.,既然客户花钱买Oracle or Sybase,那么就最大程度的压榨数据库的价值。:) |
|
返回顶楼 | |
发表时间:2003-11-09
Quake Wang 写道 比如sequence no的生成,Hibernate有多种方式可以采用,可以直接利用数据库的特性(如自增长字段等),而EE采用的是Sequence Table,这样在大量create record操作的时候,就必然要慢很多。再比如说查询方面,Hibernate也可以利用数据库的特性做分页(如Oracle rownum,Mysql limit等),而EE只使用ResultSet定位。这样对于一些数据库来说,类似这样操作的性能不是在一个数量级上的。
呵呵,这就说到点子上了。我们目前在所开发的框架中,对于 Sequence no,如果是用 Oracle 和 PostgreSQL,就直接用 sequence。Sybase 则使用 Sequence Table。分页也是这样,Oracle 直接使用 rownum,而 Sybase 则使用 identity 函数建立临时表,PostgreSQL 使用 sequence 建立临时表(临时表中含有一个 rownum 字段)。总之首先以提高效率为考虑因素。 我并不反对在适当的场合使用 Store Proc,看来大家的想法都差不多。 我使用 Ofbiz 是一年多前了,版本是 2.0Beta1,已经跟不上发展了,呵呵。 有空了多来聊聊。 |
|
返回顶楼 | |