《设计模式 ● 外观》之业务场景

/**************************************************************************************************
** 模式的初衷，无非是为我们经常出现问题的业务逻辑或系统结构提供好的解决方案，不论
** 是高层的还是较低层次的；而应用模式的主要工作则是模式识别，能将单一或复合的模式
** 结合项目自身的业务特性放在适当的场景中，则需要努力追求和不断积累。
************************************************************************************************/

      本不想谈有关外观模式，但在最近面试过程中谈及某个项目时有位Interviewer问到，什么是外观……，我表示那时有些惊讶，但是没有立刻去反驳，而是直观的解释了一下外观的基本概念。下面就来谈谈什么是外观。
      Façade（[fəˈsɑ:d]）：为子系统中的一组接口提供一个一致的界面， 通过定义高层接口，使得子系统更加容易使用，另外对于系统本身来说，并不会增加任何新功能，只修改现有对象的访问方式。
     说到Façade自然也少不了远程Façade，远程Façade一般倾向于对远程对象、远程服务，进行行为方法的简化，可以根据现有的细粒度对象创建出粗粒度的接口，当然如若你考虑到多次通讯带来的时间损耗，Façade对应的远程对象同样也需要根据需要提供粗粒度接口，此外，针对本地源、远程对象提供的Façade一般情况下可以进行宏观层面的封装处理，例如：本地源、远程对象只提供单一的请求处理，但通过你定义的Façade可以提交批量的请求处理与批量响应。当然， 如果没有必要，不建议通过单独的服务方式来提供Façade，可通过本地源的方式提供Façade组件。 在实际的项目中，请看以下的场景：

§ 场景1
 项目原有的NET.TCP服务只对内部系统提供业务逻辑服务，所以暴露了以下接口：
 
 由上可以看到，每有一个业务需求增加，都会持续的增加接口方法，增加请求、响应实体，现在有新的业务需求来了：
1、 对外提供提现接口（除原有流程外，带有附加的特殊需求）
2、 对外提供批量到银行卡接口（除原有流程外，带有附加的特殊需求）
3、 对外提供账户代发接口
以上三个新需求在原有服务中主流程都有涉及到， 但还需要在不同环节附加特殊的业务处理需求（当然这块的解耦不是本次要讨论的要点，这里不考虑它）。

 此时这里存在的问题有两个：
1、 两个调用端，内部系统、外部系统
2、 每个调用端，调用不同的接口方法
导致的问题：
1、 系统方法的增加无限扩大
2、 如果接口改变，不同的调用端都需要频繁更新服务引用
3、 相同的基础请求信息不便于统一拦截（解析、安全、授权）

到这里，看看是否可以采用Façade来解决这个问题呢？
以下是我所采用的方法：
 
      其中，PaymentFacade为实现IPaymentFacade的高层外观，FacadeDirector提供外观工厂，MControlFacade为内部系统调用处理，其他三个位本次新增的业务需求外观，这里通过IRequest（abstractRequest）定义并确立关键业务类型，通过IResponse返回响应数据，各个业务外观通过XML配置的方式来驱动流向，进而完成此外观下的一系列接口封装与简化处理。

§ 总结
其实我想说的是，不能完全FOLLOW模式即模式，模式本身有很多变体，能很好的解决问题才是根本，在评价一个方法、一个模型时务必要考虑其使用的场景。