----------------------------------------------------------------------------------------------------------------------------------------------------------

 泡牛吧!

                                       希望越来越多的光棍能够泡到牛

-----------------------------------------------------------------------------------------------------------------------------------------------------------

是否应该让实体类具备丰富的业务逻辑?(转javaeye.com)
一个业务系统而言,什么是最重要的,就是业务,我们在各种书中看到的都是业务的建模,业务的建模和技术无关的,我们使用OOA的方式,分析业务的概念模型,进行所谓的领域模型分析,这些都是业务范畴的,和技术无关。

然后有了领域模型后,领域模型是一个静态的视图,他只是表明实体,属性和关联,而领域模型的行为,往往要到向具体技术映射的时候,在详细的考虑,

这就到了设计的阶段,设计阶段,我们说白了是在干什么?是在使用java语言进行领域建模的深化,POJO也好,ebj也好,都是手段,只是想把我们抽象出来的
领域模型技术化。

我们明确这个过程后,我们就明白多了,业务建模是最先要做的东西,到了后期,我们才突然想起,噢!我们需要进行业务的数据的存储,然后我们想到了o-r映射。

所以,技术实现的领域模型,应该是一个相对独立的东西,他的目标是表达业务的领域模型。

有了这个领域模型后,我们考虑序列化了,我的想法呢,就这样。

持久层需要有专门的PO(persistence object),我把我的领域模型,通过一层(叫DataMapping),把她导成PO的关系,在DAO中,最终完成数据的存取。

也就是说,领域模型不应该意识到什么叫做持久化,而持久化层,也不知道领域模型,双方靠一个映射层(DataMapping),完成转化。

领域模型并没有被直接序列化,也不应该直接被序列化,而是经过了一个转化。

当然,这只是一个思路,这个思路强调的是关注业务,然后是技术。

当然,这个思路也是看书看来的,并没有在复杂的业务系统中实践过,说出来供大家参考。
haohao   2006-08-11 11:37:45 评论:1   阅读:176   引用:0
@2006-08-11 15:21:15  hofman
需求分析、系统设计的时候,使用uml建立系统的各种模型,主要是方便客户、投资人、架构师、程序员多种角色之间的沟通,不懂程序的人也完全看得懂。到了系统实现的时候,才是程序员的事情,才与具体的开发语言相关。
实体类当然不应该有太多的业务逻辑,高耦合必然牺牲了多层设计易于扩展、维护的好处,使得多层设计名存实亡。

发表评论>>

署名发表(评论可管理,不必输入下面的姓名)

姓名:

主题:

内容: 最少15个,最长1000个字符

验证码: (如不清楚,请刷新)

一切版权属于个人(转载例外)