分层架构中的服务层-简介

引言

　　服务层不直接执行任何任务。它所做的就是合理的安排一些列你提供的业务对象。服务层很清楚业务逻辑层，也很清楚领域模型。例如：你使用数据库表模型模式的业务逻辑层，服务层会通过DataSet来进行交互。

　　很显然，服务层合理的安排业务组件，同时也合理的安排应用的服务、工作流和业务逻辑的其他组件。

　　服务层的职责

　　服务层是一个额外的层，是在两个层之间设置一个边界。

　　服务层的目的是什么？

　　在业界有很多的应用原则都很重要，在设计软件的时候要注意：分离关注、低耦合、高内聚。当我们讨论在修改一个已有对象的时候，如何才能使得它暴露低耦合，首先想到的是增加更多的抽象。在下图中我们看到了类Action依赖于具体类Strategy，因为Action的一个方法中引用了Strategy类。

　　

　　如何降低依赖呢？而且还有一条原则：针对接口编程，不要针对实现编程。在设计的时候，应该在Action类中隐藏Strategy类。为Strategy类定义一个接口，然后定义一个工厂类来创建具体的Strategy实例，这样Strategy的修改不再影响Action类，降低了Action类对Strategy类的依赖。

　　除了高级别抽象的工厂模式，服务层还有很多模式。服务层位于一对接口层之间，保持他们的低耦合和相对的独立，但是可以很好的和他们进行通信。大多数时候，我们看到的服务层都是在表现层和业务逻辑层之间定义一个边界。这是常见的解决方案。

　　

　　合理的安排系统行为

　　正如你在上图中看到的，服务层想表现层屏蔽了业务逻辑层的实现细节。但是，他不仅做了这些工作。上图是正确的，但不是全部。

　　在他的核心中，每一次用户驱动的交互都有两个参与者：表现层实现的用户接口，服务层实现的响应用户行为的模块。这也证明了服务层不仅仅是合理的安排业务逻辑，而且它也和表现层打交道。

　　任何来源于表现层的交互，在服务层都会找到一个响应。基于收到的输入数据，服务层控制业务组件，包括：服务、工作流、和领域模型，当然了访问数据库访问层也是必须的。

　　是否服务层只是直接进行数据库操作呢？不是十分准确，业务逻辑会包括工作流和业务服务。业务逻辑应该独立于任何数据库细节。

　　服务层是表现层和其它层之间的边界，它获取和返回数据传输对象，然后将数据传输对象转换为合适的领域模型类的实例。每一个通过服务层暴露的方法都整合了其他服务、工作流和通过ORM进行了数据库操作。

　　什么是服务？

　　抛开相关的技术，服务一词简单的代表一层发送给另外一层的软件请求。服务层，就是一系列服务的集合，在两个相互通信的层中间的一个层。

　　什么是面向服务？

　　面向服务是一种将业务处理看做是一系列相互连接的服务的设计方式。面向服务不是技术本身，只是一个完成描述业务如何操作的不同的方式。

　　服务 vs. 类

　　在应用的设计中，面向服务允许你使用固定接口的独立组件。这些组件随时可以替换，只要保持接口的协议不发生变化，都不会影响系统。

　　使用服务层的好处

　　服务层在用户接口和其它层之间提供了唯一的协议，使得你可以专注于应用逻辑。应用逻辑是业务逻辑的一部分，直接产生于用例。

　　在服务端，被执行的服务层方法，合理的安排了需要的逻辑，通过协调领域模型、特殊的应用服务、工作流。

　　没有服务层，表现层就会直接调用业务逻辑层。完成一个任务，就可能需要进行多次的远程调用。对于性能来说，这不是一件好事。