robbin 2003-09-12 19:11
>>30几个表，CMR关系复杂性一般，有几个一对多的关系

这种表对象复杂度，这种规模的项目，用CMP到也真的不会遇到什么障碍。那么提两个问题：

1、ejbFind 一般查询的数据量有多大？有没有上千甚至上万条记录？

2、项目中有没用动态条件查询？举个例子吧：比如说有这么一个页面，搜索员工，可以按照年龄，性别，部门，级别来查。用户可以只按照某一个条件来查，也有可能按照某几个条件来查，也可能所有条件都用上，因此假设页面上，每个条件都是一个下拉列表框，用户可以任意选择某几个条件来查询。这样的例子如果有，你怎么办？

Horser 2003-09-12 21:17
可能robbin兄对几十个表这样规模的项目不放在眼里。但是对于大多数项目来说，可能连这个规模都未必到的了。我的这个项目ejbFind每次一般只查询为数不多的数据量，但最大时也在三五千条记录，我做过测试，好象没什么错误。虽说时间上比JDBC要慢了一些，但项目对速度要求不高。另外你提到的动态查询的问题，我想我会在Web层就生成查询语句，可能这样比较笨，但技术复杂性都不高，好维护。――我向来反对用很花哨的编程技巧来做项目，而宁可多写些易懂好维护的代码。

――我喜欢学习技术，而不是技巧。

bruce 2003-09-13 00:06
感觉Horser是有了先入为主的思想。在计算机这一块，其实大家都知道，技术更新很快，不管是主动学习也罢，被动学习也罢，几年前的技术都得退伍，所以为什么不用一种open mind的方式去看新的东西。其实很多东西都是相通的。

的确，满足项目要求是根本。但设计出更灵活，效率更高的软件不是更好吗？这不是一个OverEngineering的问题，如果你追求完美的话.

我最近测试了一下sessionBean + Hibernate 与 SessionBean+CMP的性能，App Server是 Weblogic7, 基本的代码是在以前测试JDBC与Hibernate性能基础上改进的。如果大家有兴趣的话，也可以自已测试一下，两者一对比，自然很多争论就不言自名了。

我测试的结论是数据量越大，Hibernate优势越明显。(怎么贴图功能不行了)

robbin 2003-09-13 00:50
To Horse:

我原来也一直很喜欢用Entity Bean，后来真的是因为一个大项目的惨败，使我开始重新思考EB的意义，很多原来不去想的问题都开始思考。你这样规模和复杂度以及查询量这么小的的项目我说心里话，完完全全避开了CMP的弱点。

我从前一直用EB也很好，我相信自己的EJB经验就算不比你多，也不会比你少很多。但是一个ERP类型的大项目用EB彻底的惨败！就是现在我回想起来我也很难找出一个用EB能够完成它的方案。那个时候我们讨论了很久，想了很多办法，最后发现只有抛弃了CMP，项目才能做得下去。当然没用勇气抛弃，后来失败了。现在以我的Hibernate经验，那个项目做下来会轻松的太多了。

robbin 2003-09-13 00:52
既然你对Hibernate有偏见我也不和你在Jdon上争Hibernate的好坏了，有兴趣的话，可以到Hibernate中文论坛上来和我继续争论。
banq 2003-09-13 16:07
Robbin的使用CMP个人失败的经验并不能否定CMP。需要和Robbin继续讨论Hibernate技术请到他开设的论坛中。

我再三重申，CMP是目前大多数J2EE成熟产品如Weblogic websphere和Jboss支持的技术。

CMP作为一种成熟的数据库持久层技术，一个项目如果因为使用这种技术而导致失败，那么我想这是除了SUN公司被收购或倒闭之外的另外一个全世界重点新闻。

一个J2EE或EJB项目开发是否成功，和项目的架构设计非常有关系，前面我已经说过，EJB本身就是框架，限制你任意”自由发挥“，如果你不真正掌握EJB原理，遵循EJB设计模式去使用EJB，那么你的EJB项目必定会失败，Robbin的这个失败的EJB项目我认为基本是这个原因。

CMP或Hibernate只是具体技术之争，其实争论毫无疑义，Jdon论坛提倡建立一个有思想深度的论坛，大家通过交流，讨论软件重用性、设计模式以及框架设计等更深入层次的设计。

因为软件必然是要走向规模生产，软件生产最重要的因素是开发效率，我认为，一个软件系统由两大部分组成：针对本应用的新设计和可重用的软件组件或框架，如果后者部分占据越大，无疑，需要实现的新设计或实现工作量就越小，生产效率越高。

banq 2003-09-13 16:12
另外，也请个别道友发言稍微慎重一些，关于一些技术性能问题还是以原产地或国外权威机构测试为重要。

勿以自己喜好来左右科学的东西，科学东西更需要冷静和理性，而不只是纯粹的热情，勿发表一些片面极端的观点，我们自己都是普通人，J2EE领域相当广泛，技术无顶，勿要以个人的失败来完全否定一些标准的技术。

要深入检讨自己有哪些做得不够，还需要在哪些方面提高。

banq 2003-09-15 13:40
关于那次讨论，实际是先进的非标准技术和成熟的标准技术之争。这个争论本身实际是毫无意义的.

我主要是发现一些言论是会产生明显误导倾向，或根本是错误的，特别是对于框架的认识等，所以我才会在这方面进行了反驳。只是由于争论双方无法站在对框架统一认识的基础上，所以我没有继续讨论下去，但是我放弃讨论不代表我承认一些观点。

这个讨论不是EJB本身设计优缺点的讨论，技术本身是中立的，EJB是J2EE重要而复杂的技术，在很多大型系统包括ebay（收购易趣30%）已经运行多年，这些都证明EJB本身优点是大于缺点.

当然任何技术都有缺点，否则技术不用发展，但是我们需要把一种人为的缺点和正常的缺点区分开。

所谓人为的缺点，就是没有学会正确使用EJB，或者胡乱使用EJB，导致EJB项目失败，如果从这方面认为EJB是有缺点的，那是片面和错误的，我本人也非常反感这种武断的判断，因为这会误导更多EJB初学者。

jdon网站近期将会完全使用Struts+EJB+CMP（DAO）框架实现更新，包括论坛，所有这些都是无非想从实践角度来证明成熟技术的合理使用是多么重要，在Java中，设计模式 、思想和框架远远重于java语言本身甚至其具体的技术。

O/R Mapping产品也无法是向有利于对象化、进而有利于框架设计这个方向发展，但这里面还是有一个标准的问题。

在Java世界，之所以是百家争鸣，显得乱，但是不失去章法，关键是有标准，有SUN为主导倡导的标准，这是java世界生存的基本之道，目前这个标准只有偏弱，而不是过分，有人预言，Java的最大问题可能由于其乱了失去章法，自我毁灭，所以标准在Java中是主心骨，非常重要的地位，虽然SUN没有从标准中获取多少利润，但这种精神值得很多著名的软件公司来学习的。

JDO 2.0作为标准，有很多ORM领域专家参与制定，他们制定的标准和EJB一样，应该是成熟，而且是对用户负责的。

Jdon论坛欢迎更多来自实践原创讨论，而非抽象空洞的争论，这也是我以前很少发表这些方向性问题言论的原因，但是没有这些高度问题的正确讨论，这个阵地就会被错误言论替代，从而误导用户，最综对java本身产生伤害，这是作为一个专门为Java设立网站的Jdon所不愿意看到的。

希望这些抽象问题讨论到此结束。谢谢配合。

liloboy 2003-10-14 02:39
我非常不喜欢banq的话里面的结论
================================================================
关于那次讨论，实际是先进的非标准技术和成熟的标准技术之争。这个争论本身实际是毫无意义的.
================================================================
您难道不认为成熟的技术标准存在着改进的需要嘛?而明天的成熟的技术标准难道不是今天的非标准技术嘛?

如果是的讲到Java方面来说,那么JCP的人的工作是不是都是毫无意义的哪?
那么netscape的swing的也不就是毫无意义的嘛?

其实技术无好坏,但是技术是为人服务的,如果某项技术是能够节省时间,降低开发难度和提高开发和运行效率,那总要比硬要按照EJB的模式写八股Bean好吧!

其实请你仔细读读robin的项目的条件和你所做的描述,您的system还没有经历过真实数据的考验吧?只有上千条数据和30几个表?没有动态的数据查询?换句话讲,如果您用EJB有什么解决的高招,不妨share一下,我想有很多人会感激涕零的.

而robin做过的系统无论从规模上和复杂度来说都比您的系统上要大,那是不是说明EJB的scale性能(both开发and运行)不好哪?对于一个自称为在这方面优秀的软件是不是有点讽刺哪?

其实大道至简,能十全十美固然好,但是在要求灵活度的和变化的今天,大概没有什么系统能只用EJB的技术就可以实现吧?如果不能,是不是要用一点其他的手段哪?能抓老鼠的就是好猫,这又有什么可以奇怪的呢?除非老兄是SUN或者是卖App Server的.

从这个态度来说,我觉的就是这种态度导致了EJB现在的尴尬处境.不是机制上入手,而是要强调要样这样那样的performance patterns,老天,这是个技术简化的世界,你不怎么做,有人这么做(比如微软的.net)

其实,我来谈谈我什么要用EJB,其实不就是为了Distribute可以scale嘛,除了这个原因之外,您还能说出其他的理由嘛?那又为甚麽要我自己写乱七八糟的HOME接口哪,xdoclet的工作其实给EJB container做不好嘛,不应该嘛?

其实好好想想这些问题的答案,看看robin等人所说,banq兄就不会说别人是毫无意义的这样了,这样至少也可以赢得别人的尊重!

mep 2003-10-14 09:13
各位在这里争论CMP和Hibernate，将他们互相比较，不过我倒觉得这是一个苹果与桔子的问题。

CMP并不是一种O/R，它仅仅定义了一种访问持久对象的API；在EJB规范中并没有定义CMP如何将对象映射到表中（虽然很多app server的做法。。。），如何进行O/R完全是app server vender的事情；映射的如何也和app server的质量有关系。甚至可以开发一个J2EE的app server，使用Hibernate来实现CMP（有人做过这样的项目吗？）。

CMP和JDO具有某种程度上的可比性。他们都定义了访问持久对象的API；但同样，他们都没有定义如何进行O/R mapping。

mep 2003-10-14 09:13
各位在这里争论CMP和Hibernate，将他们互相比较，不过我倒觉得这是一个苹果与桔子的问题。

CMP并不是一种O/R，它仅仅定义了一种访问持久对象的API；在EJB规范中并没有定义CMP如何将对象映射到表中（虽然很多app server的做法。。。），如何进行O/R完全是app server vender的事情；映射的如何也和app server的质量有关系。甚至可以开发一个J2EE的app server，使用Hibernate来实现CMP（有人做过这样的项目吗？）。

CMP和JDO具有某种程度上的可比性。他们都定义了访问持久对象的API；但同样，他们都没有定义如何进行O/R mapping。

shenli 2003-10-14 13:25
J2EE规范都没有定义实现啊...
如果这样的话第一个不可比的就是.NET和J2EE了
PS.jboss要用hibernate来实现CMP和JDO?
charlie 2003-10-15 17:10
首先 ,CMP ,Hibernate 都是简化软件开发的工具，存在就有其合理性，不要一棍子打死谁。
CMP ：
1：标准，应用服务器都支持。
2： 支持分布式的事务过程。
3：CMP 不是O/R MAP 工具，其实设计cmp时，是满足
1)单独 （远程客户端（WEB client, application ）直接通过RMI访问)
2）远程的(rmi(iiop) enable)
3)业务逻辑（CMP 中实现相关的业务逻辑）。但实际应用中，由于性能原因(local interface ) 1) 2）3）的功能都被SESSION BEAN封装实现了。
这样CMP 就只剩下简单的O/R map 功能了。
4)部署配置较复杂，不同应用服务器都有不同的特定配置。

Hibernate
1： 就是O/R map工具 ，将数据库数据映射为PO，实现特有的HSQL 语言，简单，易用，简化开发。
2： 丰富的文档的例子，上手快。
3： 目前的不足是分布式事务过程的支持。

在下的一些愚见，欢迎指正

robbin 2003-10-15 17:34
CMP是目前唯一支持分布式事务的技术，在可以预见的将来，Hibernate也不会支持分布式事务。其实分布式事务的效率非常低，一般用到的场合很少。