发帖    主题    评论    推荐    标签    作者    订阅    查搜    注册   登陆   关注
 
面向对象 设计模式 领域驱动设计 企业架构 框架 开发教程 微服务 大数据 扩展性 并发编程 事件驱动 分布式 SOA
1 2 下一页 Go 2

从Jive2到JiveJdon3看OO发展轨迹

                   
2007-07-09 14:52
赞助商链接

OO面向对象概念虽然出现很久,但是其间也经过较长的不断完善和发展过程,这也是很多初学者总是有“只闻其声,不见其影”的疑惑, 下面我从Jive论坛这个缩影来看看OO思想和技术的发展轨迹,从而说明今天OO已经全面进入成熟普及阶段。


http://www.jdon.com/artichect/jive_oo.html

2007-07-17 16:49

客观滴说,除了越搞复杂,并无发现有何重大技术创新。

2007-07-18 10:01

>除了越搞复杂,并无发现有何重大技术创新。
简单了还需要人参与做什么呢?见我另外一个帖子"求建模意见及建议":
http://www.jdon.com/jivejdon/thread/32246.html

由于MDA和MDSD发展,业务专家(不懂软件 但对业务精通)借助MDA和MDSD工具直接进入原来属于软件人员的领地,也就是说:业务专家不但进行建模分析,也进行设计,最后借助MDA或MDSD工具生成软件人员认为复杂的Spring+Hibernate之类代码架构。

你问我未来软件人员的位置在哪里?两个:
1. 依靠面向过程设计那些旧代码苟延残喘。
2. 依靠OO思想,掌握机器不能替代的复杂软件设计编码工作。

软件人员和工人一样,也会遭受来自自动化流水线的挑战,下岗或转岗。这是必然的。

所以,如果软件人员还是以复杂简单来对技术挑三拣四,这就象计划经济时代的养懒了的工人,对自己工作吃苦怕累,最后,简单的工作也轮不到你软件人员来做,MDA或MDSD自动化工具(类似自动化流水线)已经替代你了,软件人员只能做复杂软件的工作。

所以,个人奉劝,无须以简单好用来要求现在软件技术,如果做到简单好用,也轮不到什么都不靠的软件人员来用,业务客户就可以直接借助MDA/MDSD工具直接完成软件实现了。

这些都是软件走向更加专业的一个标志。否则象国内现在什么人都可以转行做软件,一个专业如果是什么人还能做就不能称为专业,这些都是暂时畸形形象。

[该贴被banq于2007年07月18日 10:07修改过]
[该贴被banq于2007年07月18日 10:08修改过]

2007-07-19 10:34


banq兄,
在实践中,要是按照DDD领域建模,从需求分析的领域模型,逐渐过渡到设计模型,一次次迭代,两种模型(类图)很难match,因为在分析阶段的model里面有方法,在真正实现时,都移到了DAO或Service里面,而DAO和Service是无状态的,Domain其实已经不是Domain,而是Entity(所谓贫血模型)。难道领域模型只用来做描述、理解、分析业务不能直接映射成代码实现? 如果用hibernate,spring 等框架很难实现领域模型(用AOP静态织入勉强可以做到),Spring+hibernate里面的业务本质也是Transaction Script方式(《Patterns of Enterprise Application Architecture 》。如果领域模型不能很好映射成代码实现,对编程有直接的指导意义,那领域模型似乎就高高在上,设计和实现岂不是脱节了?如果不能像ROR自然平滑实现DDD,那spring+hibernate等框架本质还是面向数据表的编程,只是这个数据表不是真正的表而是贫血的POJO,因为hibernate只是个data Wrapper,或者本质就就是.

2007-07-20 11:06

Spring+Hibernate的使用很容易产生面向数据表的编程,但不能认为它本质上就是。还是使用方式也就是指导思想的问题。打个比喻:同是一把剑,根据武功秘笈练的和普通朴素自己练的效果就完全不一样。Evans DDD是这样一个较好的武功秘笈。

这个问题又类似当初EJB争论,虽然EJB2.0不是很OO,但是如果使用得当,并不会产生传说中那么多缺点,当然Spring/EJB3更进了一步。

话又说回来,Spring+Hibernate使用DDD的平滑性是不如ROR,但是软件不只是由对象化分析设计开发组成,还由对象化组件拼装构成,Java世界这么多年已经发展了大量对象化组件,我们可以将它们作为构件来构建我们软件一部分,这个同样也很重要,特别是对于构建复杂软件更是这样,而Evans DDD的优点就是体现在复杂软件上。所以,我依然认为Java在对付复杂软件上更胜于ROR,Java是平衡的。


>在真正实现时,都移到了DAO或Service里面,而DAO和Service是无状态的,>Domain其实已经不是Domain,而是Entity(所谓贫血模型)。
Evans DDD已经将Service纳入模型概念,领域模型三个形式:实体模型 值对象和服务。无论存在形式如何,业务逻辑需要扎根在领域层(服务也分领域层和应用层)。

另外,我个人观点:不要被所谓贫血模型概念误导,这又是一个没有准确定义的概念,就象当初POJO一样。不是说将所有行为都放入领域模型就是胖模型了,Jive2就采取了胖模型,但是这样结果导致更多耦合和纠缠。

就是采取更优雅的通过AOP织入,我注意到有人开始将save等操作放在模型中,这个我个人认为不妥,save属于对象持久化,属于对象生命周期的管理维护动作,一个对象不能自己对自己生命周期进行管理维护,这其实是很正常日常生活常识。我们人都是由父母给予生命的,不可能自己创建自己,万事万物的生命都不是它自己创建的,或它自己来管理维护。

>难道领域模型只用来做描述、理解、分析业务不能直接映射成代码实现?
根据我的经验和JiveJdon3,基本可以根据Evans DDD来直接映射到代码。比如JiveJdon3中有大量帖子过滤,例如对HTML过滤,对特别关键字过滤等等,这些都属于论坛这个功能业务,所以,应该放在领域层,但是又不能直接在代码形式放入ForumMessage这个模型中,这时就可以通过Decorator等设计模式来巧妙实现。

>从需求分析的领域模型,逐渐过渡到设计模型,一次次迭代,两种模型(类图)很难match。
只能说模型图逐渐复杂细化,设计模型更加细化,是随着我们对需求认识的不断深入的产物,这个不断迭代深入的模型图才应该是唯一的模型图,不存在两种或几种模型图。










2Go 1 2 下一页

赞助商链接

赞助商链接

返回顶部

移动版 关于本站 使用帮助 联系管理员 最佳分辨率1366x768
OpenSource JIVEJDON Powered by JdonFramework Code © 2002-20 jdon.com