“但是Hibernate/JDO出现，更加会强迫他们转向MDA思维。”我不是记得banq一直也不喜欢这些持久层框架吗。我也不喜欢这个，因为，实施起来，等于又多加了一层，我还是喜欢面向表编程。我们关键是要讲效率，看实际的情况。当然，理论上，Domain Model确实很完美，但是，实际中确实谎言。可能我还不会用，用不好。估计，用习惯了可能感觉很自在。不过，那样让我的程序员，会感觉很累。并且把经历都放在学框架，找银弹上了，还不如，仔细设计好，我认为，一个系统的成功，不是在那些domain model,而是其他一些类的设计，不如那些业务对象，动作类的设计。
“不如那些业务对象，动作类的设计。”更正：
比如那些业务对象，动作类的设计。
ooa是为考虑如何真实反映客户服务业务，而ood是为了考虑如何实现应用，ood是为coding和开发效率服务的，同时要兼顾系统的性能。其实实体关系模型和域模型，单纯从模型的角度来看并不是格格不入的，其实这两种模型有很多地方是类似的，不匹配一般发生在的把域对象持久化到关系型数据库的时候，关系型数据库不能完全表达域模型，特别是域对象的关系比关系型数据库的关系复杂。其实如果有了关系实体模型，再来建域模型也很方便，但有个前提就是关系实体模型也够正确的放映业务实体和它们之间的关系同时符合关系实体规范，你可以就把关系实体模型看成静态域模型，每张表对应一个类，再根据动态模型给这些类分配适当的方法就可以了和处理对象间的关系就可以了，我就是这样干的
呵呵，我们只是探讨，目前没有谁对谁错。
其实，你说的业务对象可以使用Domain Model实现，动作类我们一般用Componet Model如SLSB等Service实现。
―〉不妨听我讲一个最近的story。OOPSLA2004，Martin Fowler带着一帮人玩了个投票游戏：GoF的23个模式当中，哪些应该被淘汰出局。结果是，Factory Method、Flyweight、Bridge、Interpreter被全票淘汰，Singleton和Chain of Responsibility褒贬参半暂时苟延残喘。
如果在J2EE的范围内做一次正式的投票，我敢打赌Factory Method、Prototype、Singleton和Bridge绝对是在被淘汰之列，因为它们做的事情已经完全被支持Dependency Injection的容器包办了，程序员再也不需要知道这些模式。所以说呢，“Singleton是邪恶”的或者是一个非伪命题，不过更可能是一个伪问题，因为……谁还需要Singleton呢？你只需要PicoContainer或者Spring Core。 〈-
我比较，赞同这段话。另外，可能你对设计模式研究太深了，模式是什么？
难听点那是枷锁。你提到“如果我们采取面向Domain Model之后，很容易就会使用设计模式”我很少受那些模式的影响，那些模式我都自己曾经重构出来过。我看到你写的一些程序，受模式影响太深了，反而把程序写的没灵性了。有点为了用而用的嫌疑。若是，根据现在一些比较新的思想来看，完全没有必要那么办。不过，这也不能愿你，毕竟思想是发展的，你只能从gof中阴影中走来，也不能怪你会那么写拉。毕竟，你为我们后来者作出了不可磨灭的贡献，我想你的名字将会在中国的java史上留下的。我认为，下个同样美好和艰辛的时代，我们80年代的develpers的时代，定会在思想上彻底摆脱gof的影响，涅磐出自己的创新灵感和思想。
“你说的业务对象可以使用Domain Model实现，动作类我们一般用Componet Model如SLSB等Service实现”，我也是这么做的，不过我的业务对象是通过编码规范让大家达成共识的，所以对一些属性又进一步模糊化了，如feild1,feild2,feild3..等等提高了编码效率，不知对你有借鉴吗。另外，总作类，我也是用componet model,估计我们两个所认为的componet mode 可能还有些概念上的偏差，如同大家都用mvc样，水平当然相差很大了。（我不是说，你水平不如我，呵呵）。以后，还忘多多指点晚辈。
不错，我也是考虑到了mote_li 所说的，也是那么做的，我一般把表映射为struts的form而没用模型类，也没像banq那样还要在form和model类之间进行copy。这样感觉比banq那样强多了，不知banq老师，mote_li 怎么看？
谢谢banq。就现在比较流行和赞同的做法是最好以OOA或者MDA来进行业务分析和业务建模。为什么说这样好呢，因为在需求分析阶段是不考虑(而且应该不要考虑)将来系统的持久格式或方式，所以业务模型或者域模型以面向对象的方法的分析抽取然后在建立他们的关系是比较平滑和自然的。
那么后面有可能我们是直接把业务模型或者域模型系列化到文件系统，这样一点问题都不会有冲突，但往往现实是我们更多的持久格式或方式是关系型数据库，这时候麻烦来了，就是面向对象分析出来的业务模型或者域模型在关系型数据库中表达就有难度了，呵呵说白了这就是导致现在很多人虽然觉得OOA或者MDA很好但不喜欢用的主要原因。那么是不是没有办法解决他们的冲突了呢，当然不是，我们完全可以让OOA或者MDA出来的业务模型对象和数据库关系型实体做成某种关系，那就是一个composite模式。
恰好现实中很多情况是业务模型对象＝数据库关系型实体的，存在某些不一样的话我们可以经过复合来合成或分解来解决这个问题。
所以啊，面向表设计是因为现实的问题，但不是好方法，如果OOA或者MDA用的深入，一样能解决业务模型对象和关系型数据库的冲突。
而OOA或者MDA一定是趋势。呵呵，现在而言我觉得在自己的上下文(context)下，如果你觉得面向表设计能提高你解决问题的效率并且不带来其他麻烦的话，当然可以这样进行。
否则还是使用OOA或者MDA，特别是大的系统中。
有道理。
我上一贴的说法，有点极端了，从ER模型，虽然可以类和表一一对应除了纯粹用来实现多多关系的表，在复杂情况下可能不太可行，但是通过OOD也能实现一个较好的域模型。
很赞同banq的说法，ood起点可以是er模型，但是建立er模型和建立类模型采用用的方法其实有很多暗合的地方。
form和model类之间进行copy，其实很简单呀，只要你form和model的字段一致用一个工具类就可搞定，我不赞成把表映射为struts的form，因为这样做，视图变化直接会影响到后面的层，后面的层的变动也会影响前面的视图
"视图变化直接会影响到后面的层，后面的层的变动也会影响前面的视图 "
确实存在。不过这样若是，数据层变了，不影响model类拉。因为我的form和form和model是合二为一的。不知你怎么看？
就我个人的感觉，从domain model出发更容易抓住用户的需求，在分析的时候考虑怎样使对象持久化只能使我们的注意力分散到一些细节技术问题上，这样会干扰分析
nekesai说大系统时使用面向模型分析比较好，我也加上“陌生系统”，也就是说，自己难以把握的时候，Domain Object可以指引一条技术之路，按照这条可以硬着头皮分析出客户需求，
nekesai说的经历感受大部分和我相同，其实我们都是从面向数据表分析设计转过来的，只要不断提示自己，挑战自己，这些很容易做到。
我觉得鲁中正气的思路代表目前大部分人的分析设计思路，很有代表性，下面言论不是针对鲁中正气个人的，因为我觉得鲁中正气是一个自信、刻苦、认真、好学的程序员，这些都是难能可贵的。
正如本文楼主提出的疑问：是什么造成了似是而非的面向对象系统？
1. 使用面向数据表分析 比较容易造成，注意不是一定会造成，如果不符合下列设计原则，那么造成概率就很高。
2. 不使用可扩展、解耦性良好的模式、框架。
正如我们前面分析，第一个条件不满足，那么第二个条件尚可支撑，但是如果不学习设计模式（不一定是GoF 设计模式）、不超越现有模式拘束，掌握分派、封装的要领，那么代码的面向对象性真是打大问号了。
所以，不管你使用如何高级的J2EE技术，用或不用EJB，如果下面两点不达到，你就很难保证你的系统是OO系统：
1. 面向模型分析
2. 使用良好的模式或框架。
当然，需要强调的是，面向模型分析MDA，我个人不非常看好自动化工具，虽然有句很极端地话：将来程序员消失，只有了建模专家，但是现实案例复杂，特别是中国国情的需求很复杂，所以，我极端地说：将来剩余两种职业：
1. 建模专家；
2. 框架设计师，他们负责把行业的通用性形成行业通用框架，具体项目只要装配，结合建模专家的分析设计具体项目的特殊功能即可。
有时写个预言觉得很过瘾。大放厥词还是很写意的事情啊。
OOA那有那么简单，记得BOOST说过，分析分析，就是让你对
软件的需求进行归类，可是现实社会当中，归类的方法又是多如牛毛
同样的系统不同的人分析，会产生不同的结果，OOA是一个经验积累的
过程，而Domain Object建模只是这些归类方法中的一种吧了，
记得去年流行什么“--”其实概念早在91年，就有，只是别人到现在
才注意他，哎，痛！
多动脑筋，多比较，多学习，多思考，自己的建模水平肯定会提高，提高多少靠悟性。