anonymous
2004-11-18 17:55

“但是Hibernate/JDO出现,更加会强迫他们转向MDA思维。”我不是记得banq一直也不喜欢这些持久层框架吗。我也不喜欢这个,因为,实施起来,等于又多加了一层,我还是喜欢面向表编程。我们关键是要讲效率,看实际的情况。当然,理论上,Domain Model确实很完美,但是,实际中确实谎言。可能我还不会用,用不好。估计,用习惯了可能感觉很自在。不过,那样让我的程序员,会感觉很累。并且把经历都放在学框架,找银弹上了,还不如,仔细设计好,我认为,一个系统的成功,不是在那些domain model,而是其他一些类的设计,不如那些业务对象,动作类的设计。

anonymous
2004-11-18 17:57

“不如那些业务对象,动作类的设计。”更正:

比如那些业务对象,动作类的设计。

mote_li
2004-11-18 18:15

ooa是为考虑如何真实反映客户服务业务,而ood是为了考虑如何实现应用,ood是为coding和开发效率服务的,同时要兼顾系统的性能。其实实体关系模型和域模型,单纯从模型的角度来看并不是格格不入的,其实这两种模型有很多地方是类似的,不匹配一般发生在的把域对象持久化到关系型数据库的时候,关系型数据库不能完全表达域模型,特别是域对象的关系比关系型数据库的关系复杂。其实如果有了关系实体模型,再来建域模型也很方便,但有个前提就是关系实体模型也够正确的放映业务实体和它们之间的关系同时符合关系实体规范,你可以就把关系实体模型看成静态域模型,每张表对应一个类,再根据动态模型给这些类分配适当的方法就可以了和处理对象间的关系就可以了,我就是这样干的

banq
2004-11-18 18:16

呵呵,我们只是探讨,目前没有谁对谁错。

其实,你说的业务对象可以使用Domain Model实现,动作类我们一般用Componet Model如SLSB等Service实现。

anonymous
2004-11-18 18:21

―〉不妨听我讲一个最近的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的影响,涅磐出自己的创新灵感和思想。

11Go 上一页 1 2 3 4 5 6 7 ... 11 下一页