posts - 262,  comments - 221,  trackbacks - 0

最近在对之前做过的一个项目进行二期修改。鉴于之前典型的贫血结构,以及Controller--->Service--->DAO模式让代码压力都集中在service层的情况。在参考了Banq写的几篇对象职责和Domain Event的文章后,我也试着捣鼓了一下新的分层模式。贴出来和大家讨论,欢迎拍砖!

【1】层次划分:


①控制层:数据映射、控制转向、业务调用
②业务层:从用户角度出发,看到的系统可以提供的功能接口
③实体层:包含了数据与行为的实体对象
④服务层:从程序内部角度出发,为了完成业务而划分出来的细粒度功能模块
⑤仓储层:对象的构建、缓存、持久化

上面我的说法可能不是很规范,因为
DDD也没有仔细的研究,可能大家会对业务和服务层的直至有所疑惑:这里我的想法就是一个从用户角度出发的业务操作,对应到程序内部可能会被划分成多个细粒度的程序操作。

【2】协作关系:


①控制层与业务层:
※控制层提供业务层所需的原始,未经封装的数据
※控制层提供业务调用
※业务层返回给控制层业务出来结果,由控制层决定转向

②业务层与实体层:
※业务层在必要时(new,edit,delete等一系列命令操作),从仓储中加载对象
※业务层向实体层对象发出事件通知
※业务层接收实体的行为反馈

③实体与服务层:
※实体通过“服务注册”的方式,让实体具有“自我数据操纵”的能力
※实体接受到业务层的事件通知后,广播给注册的服务提供者
※服务层为需要提供服务的实体提供相应的操作功能
※实体层中包含了实体逻辑(可以自己处理而不需要依赖其他模块、层次)
※服务层中包含了服务逻辑(无法通过一个对象自身完成,涉及到其它对象)

④业务与服务层:
※当业务要求是查询要求,或者与特点对象无关时,业务层直接请求服务层
※服务层可以看成是对业务层请求的内部实现

⑤服务层与仓储层:
※仓储层的对象实体可以是:新建,缓存,从持久化介质中加载
※仓储层中包含了构建对象的Builder,否则构建和校验
※仓储层中包含了对象的
缓存缓存操作
※仓储层中包含了对持久层的访问

⑥实体与仓储层:
※仓储层构建的最终对象就是实体,仓储是实体的来源,也是实体最终的去向

下面分为两只情况来阐述协作流程:

【3】增删改请求的协作流程

图片

 

【4】查询请求的协作流程
图片

 

【5】疑惑与担忧
①这种分层是否合理?因为我想让对象通过事件来消除和服务层的耦合?
②这种把命令、查询分开来对待的做法会不会令日后的逻辑变得分散而难以维护?
③在仓储的构建过程中,有可能需要调用服务层逻辑,会不会造成服务<--->仓储的双向依赖而耦合?

写了很多~~~也有劳大家费心看看。实在不想再回到贫血模型的日子啦



-------------------------------------------------------------
生活就像打牌,不是要抓一手好牌,而是要尽力打好一手烂牌。
posted on 2010-03-23 17:05 Paul Lin 阅读(1561) 评论(0)  编辑  收藏 所属分类: 架构与性能

只有注册用户登录后才能发表评论。


网站导航:
 
<2010年3月>
28123456
78910111213
14151617181920
21222324252627
28293031123
45678910

常用链接

留言簿(21)

随笔分类

随笔档案

BlogJava热点博客

好友博客

搜索

  •  

最新评论

阅读排行榜

评论排行榜