Service Facade模式还是Command模式

调用业务逻辑的问题，一直有两大派别的做法。一种是基于service facade的设计模式 ，例如EJB的session facade就是属于这种模式。另一种是基于command的设计模式。 它们各有各的优缺点。

 

基于service facade的模式，定义了一组业务接口。看起来很简单，事实上很多项目中都是采取这种模式的，传统的web应用中，我们采取分层架构，上层依赖下层提供的接口就是这样一种模式。但后来发现一个问题，就是当我们的商业逻辑发生改变的时候，业务接口也会改变，而且业务接口中用到的某个对象改变的时候，也会影响到所有的客户端。当然在比较独立的应用，这个问题基本上不会遇到。

 

AO模式。这种模式从本质上来讲，是一种command模式，或者称为request-response模式。这样我们可以把业务层做得像web层一样，给一个request就得到一个response。这样client和server端完全是松耦合的。AO/Command/CommandDispatcher等对象的样式，并运用Spring来管理它们。这样做还有一些隐含的好处。因为command是一种通用对象（说白了就是Map），所以在传递业务对象时的同时，我们还可以隐含地传递一些系统变量，例如登录用户、用户IP、访问URL等。无论是远程调用、还是本地调用，甚至是异步调用，都可以得到调用者的一些信息。而所有这一切，都不影响业务逻辑的代码。这为我们debug系统带来了方便。（通过接口调用就很难做到这些）

 

但是AO模式最严重的问题，就在于command定义的随意性，以及业务接口是弱类型的，无法利用编译器的类型检查，给编程带来麻烦。

 

为了避免接口变动的问题，我们要求做到商业逻辑改变业务层接口尽可能稳定，尽量将核心业务逻辑放在业务层之后，将用例特定的逻辑放到业务层之外；这要求比较高的业务理解能力和系统分析设计能力，但这样做带来的回报不但是一个稳定的业务层接口，而且是一个稳定的业务层实现。而业务层的变动越小，则系统的正确性、稳定性就越有保障；而且由于业务层只包括核心业务逻辑，因此往往比较精简，易变化的逻辑都放在web层中，提高了整个系统的可理解性和可维护性。要求业务层是稳定的，就像要求数据库表结构具有稳定性一样，这个要求我们觉得并不过分，也是可以做到的，前提是整个团队必须非常关注业务、分析与设计，并有相应的流程和方法学支持。

 

象如果业务层接口变化了，而客户端还在使用旧的接口调用方式，编译器无法发现这一点，带来的风险是很大的，以前因为这个原因造成不少bug。因此，我们期望如果业务层接口改变了，IDE能够帮我们找到所有客户端的调用之处，方便我们进行统一修改，并且编译器能够帮助我们保证客户端与业务层接口的一致性。在这一点上，service facade模式较command模式优越很多。

 

service facade模式难以传递调用上下文： 这是可以通过技术手段解决的。可以采用ThreadLocal传递一个称为OperationContext的对象，OperationContext顾名思义就是操作上下文，其中封装了所有由框架提供并由框架使用的调用上下文信息，比如用户主体、角色、环境等等。业务接口不需要关心这些信息，在业务实现中也很少需要使用这些信息，而是由一些框架使用的（如权限、日志等）。当需要远程或异步调用业务接口时，OperationContext也可以通过调用客户端透明传递给远程调用代理，这些在技术上都是没有问题的。

 

在框架技术选择上，框架技术能够"帮助"或"提示"一个良好的系统设计与实现，但无法"强制"一个良好的设计与实现，因此选择与改进框架技术一定要和建立、统一并推广良好的系统分析与设计方法结合起来，并建立相关的机制来支持和保障，这一块任重道远。

 

评论

1 楼 topcat 2008-08-15  

你所说的command模式,我在alibaba的webx里看到过,确实如你所说的!