从银行WebService报文接口系统中，学习敏捷设计

Preface:

?

合理的软件架构设计其好处是不言而喻的，系统具有清晰的软件结构，良好的可扩展性，类的职能单一明确，系统的复杂度底。此前的一个实际项目中总结了些关于OO设计的实际应用，主要是围绕‘高内聚及松耦合’，‘开闭原则’的一些应用。

?

Problem:

?

目前有一个实际应用放在我们面前，为一个银行现有BI系统开发WebService对外数据接口应用，数据交换方式以预定请求及响应报文来完成，要求可以数据接口系统跨平台使用。即远程客户端发来一种XML数据请求报文，系统按类型执行查询，然后返回XML数据响应报文。

?

问题也浮出水面，通常此类系统中我们可以想像到，其中一定会有一系列的if else来判断是何种请求报文，然后再执行对应的动作，但我们如果我们这样设计，系统就违反了开放-封闭原则（OCP，Open-Close Principle），日后的扩展一定需要修改原有代码，而我们期望的是日后添加一种新报文后，只在系统中扩展新的请求、查询及响应对象来实现新需求。

?

带着问题思考解决办法...

?

补充：敏捷设计扩展知识手册

?

拙劣设计的症状：

?

1.僵化性（Rigidity）：设计难以改变。很难对系统进行改动，因为每个改动都会迫使许多对系统其他部分的其他改动。

2.脆弱性（Fragility）：设计易于遭到破坏。对系统的改动会导致系统中和改动的地方在概念上无关的许多地方发现问题。3.牢固性（Immobility）：设计难以重用。很难解开系统的纠结，使之成为一些可在其他系统中重用的组件。

4.粘滞性（Viscosity）：难以做正确的事情。做正确的事情比做错误的事情要困难。

5.不必要的复杂性（Needless Complexity）：过分设计。设计中包含有不具有任何直接好处的基础结构。

6.不必要的重复性（Needlsee Repetition）：滥用复制/粘贴。设计中包含有重复的结构，而该重复的对象本可以使用单一的抽象进行统一。

7.晦涩性（Opacity）：很难阅读、理解。没有很好的表现出意图。

?

?

面向对象的设计原则：

?

1.单一职责原则（SRP，Single Resposibility Principle）

2.开放-封闭原则（OCP，Open-Close Principle）

3.Liskov替换原则（LSP，Liskov Principle）

4.依赖倒置原则—IP，Dependicy Independent Priciple)

5.接口隔离原则（ISP，Interface Seperation Principle）

?

Solution:

?

我们初步的想法是，系统接受到一种XML请求后将其转换成请求对象，类似多态的方法，根据不同的请求对象由查询工厂来创建返回不同的查询处理类，再由查询处理类返回填充好的数据响应对象，最后转换成XML响应报文。由此思路，我们完成了UML类图设计，如下：

?

?

?

首先是RemoteQueryService接口，系统对外的WS服务由此接口完成。

?

 

1.使用xml作为数据传输方式是因为银行对外业务接口确定为xml报文形式，也就是客户方的要求，这个是项目签订时所定，另外银行内多套系统间都使用xml报文形式，相当于一种契约，这个我相信大家都能理解，作为项目经理也没有必要在这个需求上引导客户。

2.如果是简单的参数请求我当然喜欢第一个，不过这里是个请求报文的简单例子，其中accountid可以有很多，在函数实现时传入大于5个以上参数时，调用方也很麻烦，因为需要知道参数顺序

 

addUser(String xml);

的好。

简单的说：远程调用接口跟本地调用接口使用相同的设计原则即可。无需将远程调用接口XML化。    35 楼    wenfuchang    2011-03-04              银行项目进度很紧，通常关注业务的时间远比关注技术实现的时间多很多，所以很多实现是拿来主义。

以前的汇票项目通过一个“中间代理平台”调用核心记账接口，规定使用WS与“中间代理平台”通讯。

另外一个项目使用XML-RPC，没有跨语言需求

还有一个是http+XML，XML是业务数据