本篇主要是为后文做铺垫，所以理论的东西相对而言比较的多一点！

　　服务层的概述

　　首先解释一下什么是”服务Service”，从广义来讲：只要是你使用了别人的东西，那么你就在使用别人提供的服务。在这里，服务就是指可能被一个或者多个系统使用的核心的业务逻辑，我们可以把服务简单的想象成为一些可供调用的API。

　　在之前的第四章中，我们讲述了如何组织业务逻辑，第五章讲述了在业务层的设计中可以采用的一些模式。但是还有一个问题需要大家考虑的是：如何把业务层提供给其他的层来调用？

　　可能认为这个问题有莫名奇妙—不是只要引用业务层的组件就行了吗。但是仔细想想，却不尽然：因为在很多系统中，我们不是直接把业务层的组件引用就可以了的，特别是在分布式的系统中，我们往往在服务端暴露一些服务接口，让其他的子系统或者外部系统来调用提供的服务。

　　一般来说，服务层处于业务层和显示层之间(当然服务层也可以处于系统和系统之间)。服务层往往提供了一些供外部调用的服务接口，这些接口往往是一些粗粒度，或者说提供了一些简单易用，功能强大的接口，当客户端调用这些接口服务之后，服务层那边就开始处理比较复杂的一些业务逻辑，验证规则，以及持久化数据等。

　　服务层内的逻辑的组织形式有点类似我们之前在第四章中讲述的Transaction Script模式。

　　我们可以简单的把服务层看成是一个中介：从客户端接收请求，通过一系列的步骤之后，请求就到了服务层，服务层就开始协调和组织所需要的业务类，把请求的的具体处理交给那些业务类来做，最后把结果返回给客户端。

　　在服务层的逻辑组织往往是比较过程化的，但是和Transaction Script有一点不同的是：Transaction Script的每一个方法处理一个比较细（比较具体的，小的）的业务流程和逻辑。但是服务层的一个接口的方法往往是处理一个比较大的流程（这个大的流程可能包含很多的小的流程）。

　　下面我们就来就从一个例子来看看SOA。

　　SOA架构讲述

　　我们首先来看一个例子：

　　上面的图就是一个电子网站的系统架构图。可以看出，在这个系统中，又包含很多其他的小的子系统，而且每一个子系统都有自己的业务逻辑。同时每一个系统都连接搭配同一个数据库，所有的子系统也都同时使用一个SMTP服务器。而且还有一些系统，如Order Management还需要链接第三方的WebService(PayPal).

　　这种错综复杂的系统架构存在一些问题：

　　1． 因为整个大的系统中存在很多的子系统，而且这些子系统都有自己的业务逻辑层，这样就导致了相同的业务逻辑在很多的其他子系统中重复，维护起来很困难。而且相同的业务流程在一些子系统中重复出现。例如，在Customer Management中，需要查看一个客户的所有的订单，那么这个逻辑和Order Management中的一些逻辑重复。

　　2． 各个系统和底层的数据结构紧耦合。因为这些系统都是用的是同一个数据库，有着各自的业务逻辑和数据访问层，那么一旦要对数据库做一点点的改动，那么就会牵连很多的子系统做相应的改变。

　　3． 审计跟踪比较的麻烦。因为很多的子系统各自可以操作数据库，所以记录操作系统比较麻烦。

　　通过SOA可以解决上面提到的一些问题(当然，不仅仅只是上面提到的一些问题)：把所有的业务处理放在一起，进行统一管理和控制（而不是像上面的设计那样—零散的到处分布），并把业务逻辑的通过服务的形式暴露会给外界，让其他的子系统调用。

　　上面改良后的系统的好处如下：

　　1． 系统的业务逻辑等的维护变得容易，因为改变只是发生在一个地方。

　　2． 并且服务都是通过接口的形式暴露给外界的，那么这就为以后的扩展提供了可能。例如我们可以在接口不变的前提下，替换现有的一些业务流程处理方式。

　　3． 日志，审计跟踪容易实现。

　　4． 对外界隐藏了数据层的实现。只要接口之前定义的数据的scheme，或者说数据契约不变，服务层可以任意替换数据存储设备和方式。

　　5． 各个系统与服务层的交互是基于粗粒度的接口，避免了系统直接和数据库频繁的交互，减小了通信的成本，也减轻了数据库的压力。

　　SOA的基本原则

　　SOA架构中，继承了来自对象和组件设计的各种原则，如封装、自我包含等。那些保证服务的灵活性、松散耦合和重用能力的设计原则，对SOA架构来说同样是非常重要的。

    结构上，服务总线是SOA的架构模式之一。关于服务，一些常见和讨论的设计原则如下。 

　　1) 无状态。以避免服务请求者依赖于服务提供者的状态。

NET技术：走向ASP.NET架构设计——第六章：服务层设计（前篇），转载需保留来源！

郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。