.NET企业架构计划-服务层的上风与优势

以前很热炒跨平台，主要是由于硅谷挑战微软霸主地位的热情，但是冷静下来后，跨平台往往不是那么一回事。假设你有个软件，所谓的跨平台，你只需要为第二个平台上重新编译一次就行了，这样很难么？服务层的优点

服务层为用户界面和两头层供应了一个一致的左券，因而两头层便可专注于完成使用逻辑。使用逻辑属于营业逻辑的一部分，其计划间接源于需求中的用例。

有了运转时情况的服务能够很简单且高效地利用部分使用逻辑撑持远程挪用。在服务器端，服务层被挪用的办法将和谐并向范畴模子，专门的使用程序服务，事情流等营业逻辑构成部分倡议挪用，从而构造程序必要的逻辑。

若没有了服务层，则必要从体现层间接挪用到使用序服务中，这就会形成一个太甚于细粒度的接口，从而招致过量的交互。因而，你大概不能不为了完成指定义务实行屡次远程挪用，从功能角度上看这固然不是好的事变。

宏服务与微服务

服务层是由一系列粗粒度的服务构成的，这也叫做宏服务。宏服务是依照用例来构造操纵的，个中其实不包括任何中心营业相干的范畴模子逻辑。换句说，宏服务对发票，产物或典质等观点一点也都不懂得，而仅懂得下定单要举行的几个需要步骤，比方，反省产物库存和用户账户中的残剩点数等。

而与之绝对的使用程序服务（也叫做微服务）则位于服务器端，用来暗示使用程序特定的服务和范畴模子的功效。举例申明，微服务有实行泉币转换，和基于事情流的服务，用来盘算订购货品的数目并包管有充足的库存等。

一样平常情形我们老是保举程序利用服务层。不外有些时分让体现层间接挪用使用程序服务也何尝不成，出格是当该服务办法较为复杂，仅实行了一个单一操纵的时分。实践上，若某个操纵不必要构造多个步骤并猎取多个了局，那末体现层就是天经地义地能够间接挪用使用程序服务，即不必要服务层。

服务层的实在例子

服务层的设法从呈现到现至今已有很长工夫了，SOA也同时随服务层呈现，加强了服务层的观点并让其加倍有吸引力。也有人说恰是SOA才触发了多层架构中对服务层的使用，固然，争辩这个主题没有任何意义，就像争辩是先有鸡仍是先有蛋一样。

基于我们外行业中的履历，我们以为时至昔日，仍有一些开辟者和架构师没有了解服务层的感化及其面前的基础准绳，因而上面我们来先容一个服务层的实在的例子。

我们中的每一个人都是低级开辟职员入手下手的，也多数碰到过一些愚昧且狂妄的老板。在20世纪90年月罗马的一间办公室中，我们常常听到老板说：“Dino，我们如今就必要一个自界说的产物X交给客户Y利用。”

能够了解吗？老板就像是体现层，他所体贴的就一条指令公布给他人，比方某个司理。在老板眼里，司理表露了一系列的义务和职责，老板其实不体贴司理是怎样完成义务的，不外老板晓得司理和公司之间的条约能确保司理定时完成义务。司理就像是服务层，随后司理挪用各类资本，并终极完成义务。

环视周围，你会发明有数实在的场景都能够看作是服务层形式的使用，好比小孩子要零费钱，编纂必要作者修正，人们从ATM中取钱等。

什么时候利用服务层

服务层应当用在一切有必定庞大性的使用程序中，不外如果个复杂的回档体系或是任意的，仅仅利用几周的一时体系，那末服务层也纷歧定能带来优点。

在多层体系中，仿佛没有来由不增加一个服务层，有一个破例就你只必要利用一个前端（比方，一般的用户界面），且使用程序服务的办法与体系的用例能很好地婚配起来，这时候服务层仅仅起到一个分发的感化，并没有事情必要构造。那些复杂的，仅用来把哀求转发给营业层的服务层切实其实是有些过剩。

相反，假如你有多个前端且使用逻辑庞大，那末最好将全部使用逻辑放在一致的地位，而不是为每一个使用程序接口都写从头编写一遍。

服务层的上风

服务层增加了分外的笼统并撤除了两个交互层之间的耦合，若这一点在你的体系中对照主要，那末应当创立服务层。服务层能够匡助你完成一个粗粒度的远程接口，并下降体现层与营业层之间的通讯流量。

若服务层是经由过程服务（比方，是经由过程WCF）来完成的，那末你还能够失掉一些分外的优点，比方，便利让该层在远程实行或经由过程设置修正绑定的设置等。

服务层的优势

由于笼统是服务层最次要的优点，以是复杂体系中的服务的确有过分计划之嫌。

正如后面我们方才提到过的那样，服务层其实不必定必要利用WCF等专门的服务手艺来完成。比方，在ASP.NET体现层中，我们一样平常都从代码后置类中挪用“服务层”，固然，服务层和代码后置类部署在统一台服务器上，而若在这里利用WCF服务而不是一般的类，则会增添挪用开支，进而影响到功能。在利用WCF服务作为服务层时，请尽早并随时寄望功能的变更。若功能影响过年夜，则有需要选用另外一种服务层手艺。

服务层的地位在那里

服务层是由体现层挪用的，那末这个挪用应当是当地仍是远程的呢？和其他有关架构上的成绩一样，这个成绩的谜底也是“依据详细情形剖析”。

Fowler的第一条有关散布式工具计划的倡议就是不要利用散布式，我们要为该倡议增补一句“除非它真正可以带来优点”。你也晓得，需要性亲睦处这两个观点都充斥变更且不容易权衡，不外在详细场景中不难判别。

那末服务层应当放在那边呢？一般而言，若服务层能够简单地在各个物理层中挪动，那将是个最好的了局。如许看来，相似WCF一样的服务手艺将是你最好的选择。

或客户端是WEB页面，那末服务层最好和页面地点的Web服务器部署在一同。若网站开展顺遂，便可将服务层拆分至另外一台使用服务器下面，进而也就进步了可伸缩性。

或客户端是桌面程序，那末服务层一样平常会部署在另外一个物理层上，并必要远程会见。这个做法与软件+服务架构中的做法一样，个中客户端仅包括GUI，也就是说，全部使用逻辑都是远程的。若客户端利用了Silverlight2且服务层公布到了Internet之上，那末这就是富Internet使用程序（RichInternetApplication,RIA）的一个完善例子。
J2EE比较成熟一点，一些比较出名的企业应用软件都是基于J2EE的。以后的发展就不好说了。不过java比较烦，学.net的话，微软把很多工具都封装好了，学起来可能容易一点。

PHP的源代码完全公开，在OpenSource意识抬头的今天，它更是这方面的中流砥柱。不断地有新的函数库加入，以及不停地更新，使得PHP无论在UNIX或是Win32的平台上都可以有更多新的功能。它提供丰富的函数，使得在程式设计方面有着更好的资源。目前PHP的最新版本为4.1.1，它可以在Win32以及UNIX/Linux等几乎所有的平台上良好工作。PHP在4.0版后使用了全新的Zend引擎，其在最佳化之后的效率，比较传统CGI或者ASP等技术有了更好的表现。

ASP.net的速度是ASP不能比拟的。ASP.net是编译语言，所以，当第一次加载的时候，它会把所有的程序进行编译(其中包括worker进程，还有对语法进行编译，形成一个程序集)，当程序编译后，执行速度几乎为0。

如今主流的Web服务器软件主要由IIS或Apache组成。IIS支持ASP且只能运行在Windows平台下，Apache支持PHP，CGI，JSP且可运行于多种平台，虽然Apache是世界使用排名第一的Web服务器平台。

我的意思是.net好用，从功能上来说比JAVA强还是很明显的。

使用普通的文本编辑器编写，如记事本就可以完成。由脚本在服务器上而不是客户端运行，ASP所使用的脚本语言都在服务端上运行，用户端的浏览器不需要提供任何别的支持，这样大提高了用户与服务器之间的交互的速度。

ASP.net的速度是ASP不能比拟的。ASP.net是编译语言，所以，当第一次加载的时候，它会把所有的程序进行编译(其中包括worker进程，还有对语法进行编译，形成一个程序集)，当程序编译后，执行速度几乎为0。