对JiveJdon3中services设计的疑问

08-04-26 160649888
在JiveJdon3的源代码中,比如ForumMessageQueryServiceImp里面对MessageQueryDao产生了依赖,我觉得这样设计不合适,我觉得既然取名为service,那他只为领域对象服务,他里面应该只包含业务逻辑,而和数据库(DAO)打交道的只有Repository,其他领域对象只依赖Repository,因为banq老师说过Repository就是对象仓库(我的理解就是相当于数据库),DDD书中有句话说:对象和存储之间的双向转换,是另一种领域设计构造---仓储的职责(p105 第二段最后一句话)。

还有个问题:

对于帖子

http://www.jdon.com/jivejdon/thread/31594.html

中说的banq老师说--对于批量查询"通过借道服务来实现",通过服务,将Entity和它的大批量子对象使用专门批量查询组件实现,我觉得很合适.我的疑问是是否可以在应用层(DDD书 P49)直接调用Repository进行查询呢?如果不可以那我理解的依赖关系应该是这样:

application-->service-->Repository-->dao,service-->domin Object,

         

oojdon
2008-04-26 15:51
顶,这个问题问得好,我也想听听banq对DDD中仓储查询以及使用基于Specification(规格)的查询的理解。

不过我觉得把查询服务全部集中在ForumMessageQueryServiceImp系统显得更加清晰,如果你想查询仓储,增加一个间接层把ForumMessageQueryServiceImp中的方法移到仓储就是了。具体设计思想还是请banq出马!

-->我觉得既然取名为service,那他只为领域对象服务,他里面应该只包含业务逻辑

好像在企业应用架构模式看到,服务的无状态操作特性,可以比喻为系统的简单API,它不应该承载业务逻辑。领域逻辑我们通常实现为组件形式,然后通过IOC容器装配。

banq
2008-04-28 10:09
>Service他里面应该只包含业务逻辑,

不是这样 ,Service如果包含逻辑,这就范了MF批评的贫血模型了,模型变得贫血了,因为业务逻辑不在模型中了。

application-->service-->Repository-->dao,service-->domin Object

这个不是很正确,如果说运行关系是这样的:application-->service-->Repository-->dao,service

但是domin Object不是最后,domin Object是贯穿这个流程中,这个流程为什么能够成立,都是因为domin Object,所以,如果application-->service-->Repository-->dao,service是一个办事流程,那么domin Object就是要办的事情。

比如,你要请假,你自己写请假单 部门批 人事部门批等,而请假单就是domin Object

yekongda
2008-04-28 12:22
160649888说“我觉得既然取名为service,那他只为领域对象服务,他里面应该只包含业务逻辑”,而oojdon说“服务的无状态操作特性,可以比喻为系统的简单API,它不应该承载业务逻辑。”,到底Service里承担业务逻辑吗(Service不就是封装业务逻辑吗)另外oojdon说的领域逻辑我理解是不是业务逻辑以外的都是领域逻辑,请指点

banq
2008-04-28 12:41
没有明白我上面举例吗?

每个部门都要审批处理请假单,比如人事部门,那么你难道就认为应该把请假业务逻辑包装在人事部门吗?

Service只是一个功能部门,如人事部门,当然不应该包含业务逻辑,业务逻辑在模型中,不能因为Service会激活相应的模型进行业务处理,就认为业务逻辑应该封装在Service中,这是两码事。

猜你喜欢
4Go 1 2 3 4 下一页