锁定老帖子 主题:命令模式浅析
精华帖 (0) :: 良好帖 (2) :: 新手帖 (0) :: 隐藏帖 (1)
|
|
---|---|
作者 | 正文 |
发表时间:2012-03-19
命令模式把一个请求和操作封装到一个对象中,目的是把发出命令的责任和执行命令的责任分割开。命令模式允许请求的一方和发送的一方独立开来,使得请求的一方不必知道接收请求的一方的接口,更不必知道命令是怎么被接收、执行的,换言之,请求方关注的是结果而不是过程。 Invoker: 执行命令的引擎,可以提供执行命令所需的上下文环境。 客户端调用伪代码: 如果配合其它模式一起使用,命令模式还可以适应更多的现实场景,例如需要使用事务时,我们可以定义一个带有事务上下文控制的组合命令: 客户端调用代码示例: Spring JdbcTemplate中的命令模式尽管Spring JdbcTemplate被人们认为是模板方法模式应用的典范,但是从另一个角度理解,其实它也是命令模式应用的最佳实践。以 JdbcTemplate#query(String sql,RowMapper mapper)这个方法为例,我们可以把JdbcTemplate对象看做是命令模式类图中的Invoker,而把RowMapper看做是 Command,在query的过程中JdbcTemplate为RowMapper的执行准备了所有必要的上下文(即ResultSet),客户端(这 里是应用程序中的DAO层)的调用模式也基本符合invoker.execute(Command cmd)。 如果说上面我的结论尚显得牵强,不放看看JdbcTemplate#query(String sql,RowMapper mapper)这个方法的内部实现: 基于命令模式对传统Service-DAO架构的再思考如果要问DAO是什么,相信大多数有经验的开发者都会回答是Data Access Object(数据访问对象),但是在某些项目中,它却承担了太多的责任(太多的业务逻辑混杂在里面)。我一直反对在DAO层混杂过多的业务逻辑,DAO 实现简单的CRUD(增删改查)就可以了。业务逻辑该在业务层(Service)实现,但是实际项目中面对的一种现实的尴尬是:如果Service层仅仅 调用DAO层的CRUD方法,往往并不能实现较为复杂的系统需求。于是我们看到了两种极端:一是Service层中嵌入了数据访问代码(JDBC、 Hibernate等等,Service与DAO的职责区分已经被打乱),二是DAO层不断增加新的方法以适应新业务的需要(DAO不再是那个纯洁的 DAO了,各领域对象之间的DAO也不再有统一的接口!!)。 如果基于命令模式对这种传统的架构进行改造,会收到很好的效果,下篇文章中我会详细阐述这种设计思路。
原文地址: 命令模式浅析 (来自http://www.infclouds.com 网站) 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2012-03-22
最后修改:2012-03-22
感觉说的有点泛泛呀,命令模式是什么呢,有什么主要特点?为什么要用命令模式?适合什么情况下。楼主的文章,虽都有涉及,只是还是停留在简单地论述上。我认为,最好是遵循命令的整个流程或生命周期去分析更好
|
|
返回顶楼 | |
发表时间:2012-03-22
赞成楼上的,楼主还应该写的详细点
|
|
返回顶楼 | |
发表时间:2012-03-22
补充一下 命令模式最重要的特点:command命令记录了上下文
|
|
返回顶楼 | |
浏览 6090 次