API 设计:CQRS(命令查询职责分离)

以下内容翻译自 CQRS by Martin Fowler,有一些修改:

 

CQRS(Command Query Responsibility Segregation)指的是命令查询职责分离。这是一种我从 Greg Young 处听到的模式描述。它的核心思想很简单,就是你在更新和读取操作时使用不同的模型,这样的话,会给整个系统的设计带来深远的变革。

 

人们和信息系统交互的主流行为就是对数据仓库 CRUD 的使用,我们构思一个可以供创建、读取、更新和删除的数据模型。简单来说,我们的接口提供出来的目的就是供存储和获取数据之用的。

 

现在我们要脱离这样一种模型,看

[……]阅读全文

不,这样的 DTO!

R.Martin 本文翻译自 Oh No! DTO! by Robert C. Martin,这篇文章很短,强调的内容简单得不能再简单,也许大家早就意识到,但是,我依然可以在很多产品的代码里面找到文中所说的 “教条” 的影子,我说不清为什么,在这里有激烈的讨论,你们说呢?

 

本周我在教授 XP(极限编程,译注)的课程,我们要写给当前的应用写 FitNesse(一种测试工具,译注)的基础测试代码。其中一位程序员使用了 RowFixture(一种测试结果比较的工具,译注),这种工具需要使用 DTO(数据传输对象)并且要求其中的变量都为公有的。这时候这位程序员提出了质疑:“DTO 应该使用私有的变量和一套相应的 get

[……]阅读全文

代码的变与不变

change 哲学上说变与不变,讲的是绝对运动与相对静止的道理,在代码设计中,也有许多变和不变之间的辩证故事。

 

有一些类在创建以后,整个生命周期内都不会发生变化,这种模式被称为 Immutable Pattern。

较弱的不变模式:指的是一个类的实例状态是不可变化的,但是这个类的引用的实例却可以变化。

比如说:Visitor 模式常常是这样的,整个流程是不可变的,但是我为我的整个流程提供灵活的切入点,提供出来访问接口,供变化的部分完成。

较强的不变模式:一个类实例状态不可变,其内部引用的所有实例也不可变。

这个就比较多了,JDK 中的 String、Integer、Byte 等都是不可变的。

&nbs

[……]阅读全文

API 风云录

1 好吧,我承认我是标题党,还是让我们从一个故事开始吧。

项目的业务逻辑层需要被设计成一个具备易扩展的模式,对外提供了大小相异的 API。项目组人人头脑风暴,最后在各位的努力下,克服苦难,业务逻辑层被封装起来,一组最初的 API 被提供出来:

1、现有 Service 逻辑已经疏于管理,欠缺重构,变成了不易控制的逻辑层,接口众多,鱼龙混杂,难以规整出清晰、可用的接口给第三方(例如下游定制团队),怎么办? 
Web 应用有个特点,当你对代码的管理缺乏控制而搞不定时,可以在其上封装一层,这是一个通用的解决办法,也是一柄双刃剑。 
正如某同事“ 我们都是工程商人&rdqu

[……]阅读全文

J2EE 核心模式学习理解和记录

第 1 章:导论

模式能够:

  • 利用一个经过验证可行的解决方案;
  • 提供一套通用词汇;
  • 约束解决方案的空间。

第 2 章:表现层设计考虑和不佳实践

客户端验证:基于表单的验证、基于抽象类型的验证。

曾经在 JSP 中滥用过的助手类,通过助手类在页面和业务逻辑之间传递数据,有点类似于如今 Struts 中的 Action 作为传值模型时的情况。

表现层不佳实践:

  • 多个视图中都包含控制代码;
  • 表现层数据结构暴露给业务层或者业务领域对象,比如:暴露 HTTPServletRequest;
  • 重复提交表单;
  • 敏感资源暴露给客户端直接访问,有个原则,敏感的东西不能放在 WEB-INF 之外;
  • 胖控制器;

……

怎么区分后台视图

[……]阅读全文

back to top