5. 服务层设计
1.服务层详解
1.1服务层的由来
在设计中，业务层常常可以进一步分为：业务逻辑单元和应用逻辑单元，其中业务逻辑单元包含各种处理逻辑和验证规则；应用逻辑单元则是由服务类组成的"薄层"，负责提供粗粒度的接口方法。
服务层用来简化外部操作，同时达到解耦的目的。服务层定义了应用的边界和客户所能看到的可操作集，它封装了应用的业务逻辑、事务控制及操作的协调能力。简单的理解就是，服务层起到隔离相关业务逻辑操作的作用，并且还包含了相关的控制逻辑。
2.服务层常用的设计模式
2.1外观模式
外观模式简化了复杂子系统的调用接口，并且隐藏了子系统之间的复杂关系，只给客户端一个简单的调用接口。
外观模式并没有"封闭"子系统的类，外观模式只是提供简化的接口，所以如果客户需要，依然可以直接使用底层子系统的类。外观模式的另外一个特征就是：在提供简化接口的同时，依然将系统完整的功能暴露出来，以便被需要的人使用。
外观可以添加"智能"的功能，让子系统的使用更加方便。例如：在服务层中加入缓存机制、异常处理机制等。
适配器的意图是，"改变"接口使其符合客户的期望；而外观模式的意图是，提供了系统的一个简化接口。
2.2远程外观模式
远程外观模式通过为细粒度对象提供粗粒度的外观来改进网络上的效率的。
如果一个单一的地址空间内进行小粒度的交互，façade模式可以工作的很好，但是如果在两个进程之间做调用，这种良好的状态就不存在了。远程调用的开销很大，因为有许多的事情要做：数据可能需要编组，可能需要安全检查，发送的数据包也需要路由。如果两个进程分布在地理位置不同的两台机器上，那么就更要考虑效率的问题了。
远程外观所要完成的功能就是把粗粒度的方法调用转换为细粒度的对象，在这些情况下，远程外观可以充当许多细粒度对象的一个远程入口。
远程外观模式的使用注意事项：
- 不要把业务逻辑放在其中。任何的外观都应该是一层"薄层"，并且只是负责很小的一部分责任。如果需要工作流或协作的业务逻辑，则需要把它放到细粒度的业务对象中，或者创建一个单独的非远端事物脚本来包含他。
- 远程外观除了提供粗粒度的接口以外，还可以增加其他功能。比如：安全检查等。
- 远程外观模式在显示层和业务层之间最常用，因为它们通常处于在不同的进程中。
- 远层外观模式很多时候都是同步调用的。我们可以采用异步和基于消息的远程通信来改善应用程序的响应速度。
2.3数据传输对象模式
如上图所示：数据传输对象是一个为了减少方法调用次数而在进程间传输数据的对象。
2.4SOA介绍
Soa指出：当前系统可以而且应该足够灵活，从而允许在不打乱当前成功运行的体系结构和基础的前提下改动已有的系统结构。
2.4.1soa原则
边界清晰
服务自治
兼容性基于策略
共享模式和契约
2.4.2服务设计原则
1.给服务命名时以最大化易用性为目标
2.服务应具有精心选择的粒度
3．服务应是内聚而完整的
可以基于功能实现按的内聚进行决策，确定是否将相似的操作分到一起。
可以使用时间内聚性原则，即将在短时间内一起使用的操作分组到一起。
4.服务应对实现细节进行封装
5.服务具有无状态接口
2.4.3服务理解
对于soa而言，soa不是一门技术，只是一种系统设计思想，所以soa中服务最后被如何实现，完全取决于开发商。
类不是服务的全部。
服务的实现需要更多的辅助机制和特定的运行环境
2.4.4服务操作设计原则
1．操作表示业务动作
2.操作应该采用粗粒度参数
2.5服务层常用的消息模式
2.5.1文档消息模式与请求-响应模式
文档消息模式可以让客户端以统一和灵活的方式与服务通信，也就是让服务操作参数成为粗粒度的，即使服务升级也不会影响现有的使用。文档消息模式把客户端所有的请求信息包装成了一个信息体，发送给服务端，同时服务端的接口定义也非常简单。
2.5.2预约保留模式
预约保留模式要解决的问题：在soa中服务器那边都是无状态的，但是有些时候，我们需要通过服务器端来保存一个长时间运行的服务的相关状态，在这段时间内，客户端向服务器端发送的多个请求可能会被当成一个业务事务或一个工作单元来处理。
我们可以发送一个请求给服务器，从服务器端的响应中获取一个预约保留的唯一编号。
客户端余下的请求中都会带上这个编号，以便服务器把这些请求当成一个事务来处理。
2.5.3等幂模式
等幂模式的基本思想是这样的：每一次客户端的请求都被赋予了一个唯一的请求标识。服务端在一个存储区域检查这个唯一的标识所代表的请求是否已经被处理过了，是否有对应的响应信息，如果有那么就从响应存储设备中返回响应信息；如果有，那么处理这个请求。
