您的位置:知识库 » .NET技术

走向ASP.NET架构设计——第六章:服务层设计(前篇)

作者: 小洋(燕洋天)  来源: 博客园  发布时间: 2010-12-06 10:24  阅读: 3642 次  推荐: 1   原文链接   [收藏]  
摘要:本章的内容比较的多:讲述ASP.NET项目中服务层的设计,什么是SOA架构,以及为什么需要SOA;在服务层设计的时候涉及到的设计模式和架构模式;最后用一个WCF的例子作为本篇的结尾。

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

  服务层的概述

  首先解释一下什么是”服务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) 无状态。以避免服务请求者依赖于服务提供者的状态。

  2) 单一实例。避免功能冗余。

  3)   明确定义的接口。服务的接口由WSDL定义,用于指明服务的公共接口与其内部专用实现之间的界线。WS-Policy用于描述服务规约,XML模式(Schema)用于定义所交换的消息格式(即服务的公共数据)。

  使用者依赖服务规约调用服务,所以服务定义必须长时间稳定,一旦公布,不能随意更改:服务的定义应尽可能明确.减少使用者的不适当使用;不要让使用者看到服务内部的私有数据。

  4)    自包含和模块化。服务封装了那些在业务上稳定、重复出现的活动和组件,实现服务的功能实体是完全独立自主的,独立进行部署、版本控制、自我管理和恢复。

  5)   粗粒度。服务数量不应该太大,依靠消息交互而不是远程过程调用(RPC),通常消息量比较大,但是服务之间的交互频度较低。

  6)   服务之间的松耦合性。服务使用者看到的是服务的接口,其位置、实现技术和当前状态等对使用者是不可见的,服务私有数据对服务使用者是不可见的。

  7)   重用能力。服务应该是可以重用的。

  8)   互操作性、兼容和策略声明。为了确保服务规约的全面和明确,策略成为一个越来越重要的方面。这可以是技术相关的内容,例如一个服务对安全性方面的要求;也可以是跟业务有关的语义方面的内容,例如需要满足的费用或者服务级别方面的要求,这些策略对于服务在交互时是非常重要的。WS-Policy用于定义可配置的互操作语义,来描述特定服务的期望、控制其行为。

  在设计时,应该利用策略声明确保服务期望和语义兼容性方面的完整和明确。

  上面的一些原则可能有点抽象,在文章的后面一个例子中会设计一个小的项目,会对这些原则多一些讲解。

  今天就讲述到这里吧,没有什么很新的东西,都是为了给后文做准备的,下一篇主要讲述在SOA常常使用的设计模式和架构模式。

1
0
标签:ASP.NET

.NET技术热门文章

    .NET技术最新文章

      最新新闻

        热门新闻