>尤其cmp bean，在理论上是不能支持完整oo建模
理论上不支持？问题是现在建模工具已经实现，Rose中的EJB数据建模，你那个理论是哪门子“歪理邪说”，我知道又来罗嗦什么POJO了，真烦，不要在这里讨论。

>ooram方法、catalysis方法?
我不可能所有都了解，也不想了解我不喜欢的学说，就象你看到我提实体Bean就反感，无名火气上来.

我这篇文章不是想显示我个人水平，而是指出一个浅显的道理，这个道理对初学者是有裨益的。

我赞同先存储后计算，但是存储在哪里？以前只想到存储到数据库里，现在其实更多考虑是存储在内存里，是Cache，这也就是有状态EJB的来历，到现在SPring还没提出一个替代有状态EJB的东西，单例可是全局的啊。

前面有一个提问者反问得很有道理，按照缓存这样的概念，不也是在做数据库吗？是的，通过对象缓存确实在做数据库做的事情，沿着它的思路在深化。

raimundo 很显然不是很了解EJB，这是国内很多所谓高手的通病，不了解使用一个技术，一直在诋毁它，这是什么形象我就不说了。

我告诉你在实际中开发J2EE包括EJB是什么样的（不预先设计数据库）。你可以看看Petstore和我的JdonNews演示：
Domain Model设计出来，持久层实体Bean就出来了，编写Service，开发完成，部署这个应用，当部署时，J2EE服务器探知实体Bean对应的数据表是否存在，如果没有，就自动建立数据表（数据表字段是256长度，这些都不必计较了，在数据库很少访问情况下，甚至字段类型都是字符串都没有关系）。所以整个开发过程根本无需涉及数据库。

在J2EE多层中，对象Cache由于更靠近客户端，所以对于客户端响应来说，越靠近客户端当然越快了。而且Cache是内存，数据库要快也得拼内存计算，如果它要访问磁盘，那就更不能比了。

海量计算是另外一个话题，我这里是指企业开发，我看估计有不少人误解，离开这个前提谈数据库，那可谈远了。

我知道cats_tiger的意思，对于大型数据库应用，一个索引就可以提高几百倍的查询效率，但是这种数据库索引还是被全文检索击败（google肯定不是花老鼻子前听信Oracle宣传，用他们的数据库检索的），这是另外一个话题。

企业开发应用中，数据使用总是相对集中的，例如ERP等财务系统，几乎是当月数据等等，所以只要能频繁使用就可使用Cache提高性能。

J2EE有一个不成文的文化：第一遍总是很慢，以后就快了。例如第一次运行Jsp很慢等等，这些都是缓存原因，将Windows的缓存去掉看看，它慢得象蜗牛。

另外，也请大家不要离题讨论，更不要谈我个人怎么样，我只是想抛砖引玉，提供大家一个理性的、经过思考发言的专业场所，违背这个我会删贴的。

>理论上不支持？问题是现在建模工具已经实现，Rose中的EJB数据建模，你那个理论是哪门子“歪理邪说”，我知道又来罗嗦什么POJO了，真烦，不要在这里讨论。

我并没有说pojo, 再说rose支持ejb的“数据建模”是oo建模吗？oo model并不只是实体和关系，还有其他的，比如说banq说所说的pattern。据一个例子，ejb 2.1 entity bean做一个继承就能把人琐碎死，而且还要自己做大量的工作，这叫oo modeling吗？我不能构造自己的类型层次体系这叫oo modeling吗？banq兄怎么说着说着又转到“数据模型”上去了。

>我不可能所有都了解，也不想了解我不喜欢的学说，就象你看到我提实体Bean就反感，无名火气上来.

正好回复也可以引用"这是国内很多所谓高手的通病，不了解使用一个技术，一直在诋毁它，这是什么形象我就不说了",catalysis并不是轻量方法，而是oo方法一个发展方向，面向组件，模式，和framework。banq兄啊，除了组件不都是您的最爱吗，可以研究一下的说。

>raimundo 很显然不是很了解EJB，这是国内很多所谓高手的通病，不了解使用一个技术，一直在诋毁它，这是什么形象我就不说了。我告诉你在实际中开发J2EE包括EJB是什么样的（不预先设计数据库）。你可以看看Petstore和我的JdonNews演示

恰恰相反，ejb规范我从1.0看到3.0 draft2，都是仔细看完的哦。banq兄曾经放在首页的spring vs ejb也是不才在下写的。而且我使用ejb也做过一些项目，还用它实现过一个cwm元数据库，entity bean就有几十个。象banq兄这个JdonNews，实在是太简陋了，不足以说明问题。

>Domain Model设计出来，持久层实体Bean就出来了

再声明一次rowset gateway和domain model差别是很大的。以我写entity bean的经验，对于复杂的OO model而言，cmp根本不可能实现，不信的话，banq兄可以用cmp bean写一下CWM的foundation层以上的任意一个package。是用bmp是可以的，但是工作量是个问题。CMP本质上是RowSet Gateway。这句话起码在2.1之前没有什么大问题。

其实catalysis方法有很多要点。最重要的一点，Role，Application Logic(Use Case), Domain Model三者都是first class。其中强调role说明一个问题，就是协作在catalysis里是first class。这是ooram和catalysis方法对比传统oo方法的重要突破。
why？因为协作即模式，你看一下rose，里面的pattern repository，用什么表述pattern？协作图。所以catalysis强调协作，就是把pattern当作oo建模的一个基本要素来看待的，通过协作的组合，达到pattern的组合，也就是pattern-oriented design。推荐你看本书，Pattern-Oriented Application Development，好像叫这个名，记不太清了，副标题是通过模式组合来开发软件什么的。
pattern不断的聚集，也就是协作不断的组合，就产生了framework，bind role就是ioc，于是模式也有了。同时小的协作团可以组成内聚的个体，就是组件。组件在协作的范围内继续组合，系统就出现了。
Catalysis是我非常看好的一个方法论，去年我用了近一年的时间，把OO方法论从早期文献，书籍一直看到90年代中期。感觉catalysis是突破性最强的，而且也最有实用意义。
上次在BEA User Group上，我简单介绍了用catalysis来理解j2ee的组件结构，以及用catalysis来解释ejb3 model的产生。有兴趣的话可以加我msn，binartist@hotmail.com，我们可以深入探讨一下。

banq兄，我想说一点，cache从体系结构上来看，产生在I/O速率匹配的地方，所以比cache更有用的，是减少低速率传输层次而不是增加层次，这也就是为什么n-tier remoting应用虽然有，但是不流行，而2层，3层却很流行的原因。
banq兄一直非常推崇cache，我想是受了Marc Fleury的影响吧，Oberg也说了，序列化是万恶之源。缓解序列化的恶果，所以需要cache，怎么讲它都是退而求其次的方法，并不是用了cache就如何如何的。当然我这也是个人意见。
再有一点，"只要能频繁使用就可使用Cache提高性能"，这里有一个经典的cache失效的例子，就是cache抖动，同时cache也需要承受脏数据带来的更新成本，所以并不是任意情况下都可以使用cache的提高性能。这段有抬杠的嫌疑，banq兄可以忽略。

有几个观点还是待讨论：
>对于复杂的OO model而言，cmp根本不可能实现
其实实体Bean是Model的持久化实现，它不是Domain Model，如果你象在Hibernate里一样把它当Domain Model使用就错了，
所以Model的复杂组合关系当然无法用CMP实现，在这个环节明白就不会苛求CMP了，相反，在使用Hibernate时，如果
将Model就当成它的POJO，直接session.save(model)；我还觉得耦合性太强了，谁能说Hiberante永不淘汰？我能将其和我
的业务层捆绑在一起吗？对不起，谈开去了。

>ooram和catalysis
反映了模式Patterns和Ioc思想结合使用现状，这个是激动人心的，但从ooram和catalysis来说，我觉得有老酒装新瓶的嫌疑，
这又涉及到新学说流派问题，不磨嘴皮子了。
用catalysis来解释ejb3 model的产生，实际就是用Ioc来解释EJB3的诞生。当然我相信catalysis更能自圆其说，这好比民间
发明了新东西，国家正式机构表示正式承认罢了。当然，我也会认真学习catalysis的一些新思想。

>Oberg也说了，序列化是万恶之源。缓解序列化的恶果，所以需要cache，cache抖动，同时cache也需要承受脏数据
这正说明了Cache是不容易做的，有陷进的，就象线程池 对象池不推荐企业开发者自己做一样，好的Cache一定不能序列化；
同时要跟踪Cache效率，防止脏数据，这些都是需要根据实际情况微调tunning，目前Jdon框架中Cache是巧妙回避这些问题。
所以使用AOP实现缓存也要注意效率问题，有人曾经疑问Jdon框架为什么Cache有的不使用AOP，这也是从效率考虑的。

OO从它产生到现在都有一个问题没有很好的解决，就是modeling过程的递归化。依据图灵机原理，计算机可解问题是能行递归过程。所以递归的方法和递归化解决问题的过程是计算科学很看重的问题。这点结构化语言就作得非常好，将一段程序结构化的过程可以使用一系列递归的过程解决。但是在OO modeling里，从来都没有独大的递归分析过程，这也是oo流派格外庞杂的原因。但是目前主流的流派是职责派分，比如GRAPS之类的。在GRAPS中有一个早期原型，见于WWW84记不清了，就是entity, controller, boundary三个基本sterotype，约束oo的递归分析过程，后来又一个进化版，就是entity, controller, boundary, lifecycle。在ejb entity bean 2.x里，home是典型lifecycle, dao也是典型的lifecycle，同时，entity bean自己的lifecyle方法也是lifecycle部分。因此这是一个不好的关注分离，lifecycle散布在很多地方。好的形式，或者说更oo的形式，是这样的：

lifecycleManager.save(entity);

ejb 3就是这个形式，当然hibernate也是。我们不谈整体架构，就从对象模型上来说，ejb3/ hibernate是比ejb 2.x更好的模型(我想banq兄该不是对一个技术不喜欢就一帮子打死的人吧)。

当然hibernate不会一直存在，马克思说了，凡是存在的就比是要灭亡的。但是比较ejb3 和hibernate的object model（不是整体架构，因此不能说明hibernate比ejb好，艾，本来我也无意比较ejb和hibernate的优劣，昨天erp老师说中文不严谨容易望文生义，正是真理啊），会发现他们是惊人的一致。从这个角度来说，ejb 2.x 的object model的确是过时了。

另外一个banq兄一个论点的矛盾是，既然承认entity bean 2.x的 数据集 性质，又为什么总在说entity bean 2.x进行oo建模呢？既然承认entity bean的 数据集 性质，又为什么要说中间件不需要数据库？

因此，如果现在使用的是ejb 3或者hibernate，我们可以说oo modeling去取代er modeling，将er modeling交给中间件或o/r mapping, 但是ejb 2.x里，我们仍要关注数据库性能，仍要关注3范式和数据库设计。

说的太好了.

好!

ejb/hibernate/jdo等其他技术的目的或产生动力好吗?

我认为这些的目的是:
一避免操纵SQL,不用针对sql(或数据库)进行设计.
二,人们不喜欢复杂,喜欢简单.而OO(或对象之间)的关系要比sql简单的多.而简单，是人们一直的追求，或许和人的惰性有点关系。

欢迎大家指正.

技术,不就是为人服务的吗?

oo并不比数据库的关系简单，反而是更复杂。数据库很简单，就是集合运算，有着oo不可比拟的思维简洁性。数据的弊病在于不能刻画复杂的计算，而这时程序语言的擅长。
OO的长处在于动静相生，也就是既可以刻划数据也可以刻划行为。但是单就数据刻划而言，oo绝对不是最好的选择。比如rdf/owl, 比如er，都么比oo优秀要么比oo简洁。
我看您的blog上有一个论数据库终结的，正好我这周在beijing java user group有一个topic，关于content-centric architecture的，如果您在北京可以过来探讨一下。

OO的简单，我认为简单在关系上，那些关系，我们稍微注意都能很快明白。数据库的复杂，复杂在表与表的关系上。
如果不使用o/r mapping，我们要维护表的关系。
在系统不变的情况，是不会有很多问题。可是，系统的变化性是经常的，频繁的。我们来维护字段和表？呵呵 谁知道一个字段都在什么地方使用？（请不要拿一个人能完成的小系统来作例子）这简直是个噩梦。
而EJB也好,hibernate也好,以及jdo,包括其他O/R mapping技术,把表的维护和字段的维护屏蔽了。
转化为对象间的关系了.
那么这就简单多了.

再者,数据库仅仅是存储数据,这是最根本目的.
他不能存储业务过程,也不能处理业务过程.
也就是说,数据库在系统中的地位,不是第一的.
我们可能随时更换数据库,或更换存储方式.
OO来说,这是小菜一碟.
数据库可以吗?当然可以,那么请不要使用特定数据库的语法和函数---------我想这些不是我们希望看到的.


在某些情况下,我们更关注系统性能,比如要在google查找,1秒返回结果我很喜欢用,如果1分钟呢?或3分钟?甚至更长,我能忍受吗?
对于这样的情况,相信设计者已经考虑到这个问题,那么可能就不再单纯的使用OO.如果在系统完成后，出现这样的情况，可能要对系统进行调整。