服务层的好处

服务层为用户界面和中间层提供了一个统一的契约，因此中间层即可专注于实现应用逻辑。应用逻辑属于业务逻辑的一部分，其设计直接源于需求中的用例。

有了运行时环境的服务可以很容易且高效地使用部分应用逻辑支持远程调用。在服务器端，服务层被调用的方法将协调并向领域模型，专门的应用程序服务，工作流等业务逻辑组成部分发起调用，从而组织程序需要的逻辑。

若没有了服务层，则需要从表现层直接调用到应用序服务中，这就会造成一个太过于细粒度的接口，从而导致过多的交互。因此，你可能不得不为了完成指定任务执行多次远程调用，从性能角度上看这当然不是好的事情。

宏服务与微服务

服务层是由一系列粗粒度的服务组成的，这也叫做宏服务。宏服务是按照用例来组织操作的，其中并不包含任何核心业务相关的领域模型逻辑。换句说，宏服务对发票，产品或抵押等概念一点也都不了解，而仅了解下订单要进行的几个必要步骤，例如，检查产品库存和用户账户中的剩余点数等。

而与之相对的应用程序服务（也叫做微服务）则位于服务器端，用来表示应用程序特定的服务以及领域模型的功能。举例说明，微服务有执行货币转换，以及基于工作流的服务，用来计算订购货物的数量并保证有足够的库存等。

一般情况我们总是推荐程序使用服务层。不过有些时候让表现层直接调用应用程序服务也未尝不可，特别是当该服务方法较为简单，仅执行了一个单一操作的时候。实际上，若某个操作不需要组织多个步骤并获取多个结果，那么表现层就是理所当然地可以直接调用应用程序服务，即不需要服务层。

服务层的真实例子

服务层的想法从出现到现至今已经有很长时间了，SOA也同时随服务层出现，增强了服务层的概念并让其更加有吸引力。也有人说正是SOA才触发了多层架构中对服务层的应用，当然，争论这个主题没有任何意义，就像争论是先有鸡还是先有蛋一样。

基于我们在行业中的经验，我们认为时至今日，仍有一些开发者和架构师没有理解服务层的作用及其背后的基本原则，因此下面我们来介绍一个服务层的真实的例子。

我们中的每个人都是初级开发人员开始的，也大都遇到过一些愚蠢且傲慢的老板。在20世纪90年代罗马的一间办公室中，我们经常听到老板说：“Dino，我们现在就需要一个自定义的产品X交给客户Y使用。”

可以理解吗？老板就像是表现层，他所关心的就一条指令发布给别人，例如某个经理。在老板眼里，经理暴露了一系列的任务和职责，老板并不关心经理是如何完成任务的，不过老板知道经理和公司之间的合同能确保经理按时完成任务。经理就像是服务层，随后经理调用各种资源，并最终完成任务。

环顾四周，你会发现无数真实的场景都可以看做是服务层模式的应用，比如小孩子要零花钱，编辑需要作者修改，人们从ATM中取钱等。

何时使用服务层

服务层应该用在所有有一定复杂性的应用程序中，不过若是个简单的归档系统或是随便的，仅仅使用几周的临时系统，那么服务层也不一定能带来好处。

在多层系统中，似乎没有理由不添加一个服务层，有一个例外就你只需要使用一个前端（例如，普通的用户界面），且应用程序服务的方法与系统的用例能很好地匹配起来，这时服务层仅仅起到一个分发的作用，并没有工作需要组织。那些简单的，仅用来把请求转发给业务层的服务层的确是有些多余。

相反，如果你有多个前端且应用逻辑复杂，那么最好将整个应用逻辑放在统一的位置，而不是为每个应用程序接口都写重新编写一遍。

服务层的优势

服务层添加了额外的抽象并除去了两个交互层之间的耦合，若这一点在你的系统中比较重要，那么应该创建服务层。服务层可以帮助你实现一个粗粒度的远程接口，并降低表现层与业务层之间的通信流量。

若服务层是通过服务（例如，是通过WCF）来实现的，那么你还可以得到一些额外的好处，例如，方便让该层在远程执行或通过配置修改绑定的设置等。

服务层的劣势

因为抽象是服务层最主要的长处，所以简单系统中的服务确实有过度设计之嫌。

正如前面我们刚刚提到过的那样，服务层并不一定需要使用WCF等专门的服务技术来实现。例如，在ASP.NET表现层中，我们一般都从代码后置类中调用“服务层”，当然，服务层和代码后置类部署在同一台服务器上，而若在这里使用WCF服务而不是普通的类，则会增加调用开销，进而影响到性能。在使用WCF服务作为服务层时，请尽早并随时留意性能的变化。若性能影响过大，则有必要选用另一种服务层技术。

服务层的位置在哪里

服务层是由表现层调用的，那么这个调用应该是本地还是远程的呢？和其他有关架构上的问题一样，这个问题的答案也是“根据具体情况分析”。

Fowler的第一条有关分布式对象设计的建议就是不要使用分布式，我们要为该建议补充一句“除非它真正能够带来好处”。你也知道，必要性和好处这两个概念都充满变化且不易衡量，不过在具体场景中不难判断。

那么服务层应该放在何处呢？通常而言，若服务层可以容易地在各个物理层中移动，那将是个最好的结果。这样看来，类似WCF一样的服务技术将是你最好的选择。

或客户端是WEB页面，那么服务层最好和页面所在的Web服务器部署在一起。若网站发展顺利，即可将服务层拆分至另一台应用服务器上面，进而也就提高了可伸缩性。

或客户端是桌面程序，那么服务层一般会部署在另一个物理层上，并需要远程访问。这个做法与软件+服务架构中的做法一样，其中客户端仅包含GUI，也就是说，整个应用逻辑都是远程的。若客户端使用了Silverlight 2且服务层发布到了Internet之上，那么这就是富Internet应用程序（Rich Internet Application,RIA）的一个完美例子。