引言

　　服務(wù)層是在交互的兩個(gè)層中間又定義了另外一個(gè)層，典型的是在表現(xiàn)層和業(yè)務(wù)邏輯層之間。這個(gè)中間層只是實(shí)現(xiàn)應(yīng)用的用例的類(lèi)集合。

　　服務(wù)和面向服務(wù)的出現(xiàn)，使得整個(gè)解決方案更有價(jià)值、更加成功。與表現(xiàn)層相比，服務(wù)層提供了松散的耦合，服務(wù)層提供商定的協(xié)議，可重用性，跨平臺(tái)的部署。服務(wù)向其他類(lèi)一樣，允許你調(diào)整你需要的抽象總數(shù)。

　　真實(shí)世界的表現(xiàn)層，主要是用戶(hù)前端。用戶(hù)做的每一件事都通過(guò)表現(xiàn)層和用戶(hù)界面。

　　企業(yè)級(jí)的應(yīng)用，可能會(huì)有多種數(shù)據(jù)表現(xiàn)接口。一個(gè)接口可能就是一個(gè)用戶(hù)界面，也可能是每一個(gè)支持的平臺(tái)，例如：移動(dòng)應(yīng)用、Web、WPF、Windows、Silverlight，或者是其他軟件平臺(tái)。另一個(gè)接口可能是后端應(yīng)用，傳入數(shù)據(jù)或者是獲取數(shù)據(jù)，并且轉(zhuǎn)變他。可能還有一個(gè)接口是一個(gè)使用應(yīng)用的連接者代理-系統(tǒng)整合方案中的內(nèi)部處理邏輯。

　　服務(wù)層響應(yīng)來(lái)自表現(xiàn)層的輸入。相應(yīng)的，表現(xiàn)層不關(guān)心另外一端的操作和模塊。重要的是模塊聲明了它能做什么。

　　表現(xiàn)層和服務(wù)層都不包含業(yè)務(wù)邏輯。表現(xiàn)層只知道服務(wù)層提供的粗粒度接口，服務(wù)層只知道一系列可行的相互作用的協(xié)議，處理本質(zhì)的細(xì)節(jié)：事務(wù)，資源管理，協(xié)調(diào)，數(shù)據(jù)消息。

　　服務(wù)層在現(xiàn)實(shí)生活中的例子

　　SOA的出現(xiàn)，與服務(wù)層的出現(xiàn)一致，加強(qiáng)了服務(wù)層的概念，使他更吸引人。一些人爭(zhēng)論說(shuō)在多層架構(gòu)中使用SOA是有創(chuàng)造力的。爭(zhēng)論這些是毫無(wú)意義的，就好像爭(zhēng)論是先有雞，還是先有蛋。

　　在實(shí)際的使用中，使用服務(wù)層的目的，背后的理由，很多程序員和架構(gòu)師還未能理解。下面，讓我們分析一個(gè)現(xiàn)實(shí)生活中的例子。

　　我們中的很多人都有做初級(jí)程序員的經(jīng)歷。在某些時(shí)候，我們還會(huì)碰到一個(gè)目中無(wú)人的老板。老板可能會(huì)說(shuō)：嗨，我們需要馬上為客戶(hù)定制一個(gè)系統(tǒng)。

　　你聽(tīng)到了嗎？老板就是表現(xiàn)層。老板關(guān)心的是向經(jīng)理人發(fā)送一個(gè)簡(jiǎn)單的命令。在他的眼里，經(jīng)理人暴露了一個(gè)任務(wù)和責(zé)任的列表。老板不關(guān)心經(jīng)理人實(shí)際如何完成任務(wù)，但是他知道公司和經(jīng)理人之間的協(xié)議中規(guī)定的經(jīng)理人應(yīng)該做什么（協(xié)議中也會(huì)提到，如果經(jīng)理人不滿(mǎn)足要求，就會(huì)被替換掉）。經(jīng)理人就是服務(wù)層。最終，經(jīng)理人協(xié)調(diào)其他資源來(lái)完成這個(gè)任務(wù)。

　　如果你左右看看，在現(xiàn)實(shí)生活中你會(huì)找到很多服務(wù)層模式的例子。例如：孩子向父母要零花錢(qián)，編輯要求修改文稿，你從ATM中取現(xiàn)金，等等。

　　什么時(shí)候使用服務(wù)層

　　在任何有點(diǎn)復(fù)雜的應(yīng)用中都應(yīng)該使用服務(wù)層。如果在一個(gè)簡(jiǎn)單的文檔管理系統(tǒng)，或者是一個(gè)快速建立的網(wǎng)站，可能只是存在幾個(gè)星期的網(wǎng)站中建立服務(wù)層很可能會(huì)沒(méi)有回報(bào)。

　　在一個(gè)分層系統(tǒng)中，沒(méi)有理由不使用服務(wù)層。一個(gè)可能的例外就是簡(jiǎn)單的前端和一系列只是滿(mǎn)足用例的應(yīng)用服務(wù)。在這種情況下，服務(wù)層很可能只是一個(gè)發(fā)報(bào)機(jī)，沒(méi)有任務(wù)組合工作。簡(jiǎn)單的服務(wù)層還不如直接調(diào)用業(yè)務(wù)邏輯層。

　　相反的，在你擁有多個(gè)前端，而且是大量的應(yīng)用邏輯，將應(yīng)用邏輯存放在一個(gè)地方，而不是在每個(gè)應(yīng)用接口中都保留副本會(huì)更加好。

　　服務(wù)層的優(yōu)點(diǎn)

　　服務(wù)層增加抽象，解耦兩個(gè)交互的層。在任何你想獲得一個(gè)更好的系統(tǒng)的時(shí)候，你都應(yīng)該構(gòu)建一個(gè)服務(wù)層。服務(wù)層使用粗粒度的遠(yuǎn)程接口最小化表現(xiàn)層和業(yè)務(wù)層之間的通信次數(shù)。

　　通過(guò)服務(wù)（例如：WCF）來(lái)實(shí)現(xiàn)服務(wù)層的時(shí)候，你能感覺(jué)到其他的好處，例如：通過(guò)配置來(lái)改變綁定信息。

　　服務(wù)層的缺點(diǎn)

　　因?yàn)槌橄笫欠?wù)層的主要優(yōu)點(diǎn)，對(duì)于簡(jiǎn)單的系統(tǒng)可能有點(diǎn)過(guò)頭了。

　　服務(wù)層不是必須使用例如WCF這樣的服務(wù)技術(shù)。在ASP.NET中的表現(xiàn)層，你可以把code-behind類(lèi)叫做服務(wù)層。這時(shí)候使用WCF代替普通的類(lèi)，可能有點(diǎn)過(guò)頭了，很可能會(huì)降低性能。考慮在你的系統(tǒng)中使用WCF，需要考慮性能，如果性能下降的無(wú)法忍受，請(qǐng)選擇其他服務(wù)層技術(shù)。

　　服務(wù)層適用于什么樣的場(chǎng)景

　　表現(xiàn)層調(diào)用服務(wù)層。是一個(gè)遠(yuǎn)程調(diào)用，還是一個(gè)本地調(diào)用？

　　Martin Flower關(guān)于分布式對(duì)象設(shè)計(jì)的推薦是：不要分散你的對(duì)象。我們可以理解為：“除非是必須的，或者是有好處”。就想你所知道的，必要性和好處實(shí)際容易變化的，難以量化，但是在一些特殊的方案中，他們很容易識(shí)別。

　　因此，在什么場(chǎng)景適合服務(wù)層呢？通常來(lái)說(shuō)，如果你有一個(gè)服務(wù)層，可以很容易的跨層移動(dòng)，那是一件好事。在這點(diǎn)上，例如WCF這樣的服務(wù)技術(shù)是一個(gè)正確的工具。

　　如果客戶(hù)端是Web網(wǎng)頁(yè)，服務(wù)層最好是位于本地的Web服務(wù)器上。如果站點(diǎn)成功了，你可以將服務(wù)層分離到獨(dú)立的應(yīng)用服務(wù)器，來(lái)增加擴(kuò)展性。

　　如果客戶(hù)端是桌面應(yīng)用，服務(wù)層會(huì)部署到一個(gè)獨(dú)立的物理層，并且通過(guò)遠(yuǎn)程來(lái)訪問(wèn)。這個(gè)方法類(lèi)似于Software+Services的架構(gòu)，客戶(hù)端除了GUI什么都沒(méi)有，全部的應(yīng)用邏輯都在遠(yuǎn)端。如果客戶(hù)端使用Silverlight，服務(wù)層會(huì)發(fā)布在InterNET上，你可以建立一個(gè)完美的RIA（Rich InterNET Application）應(yīng)用。

　　實(shí)戰(zhàn)服務(wù)層模式

　　實(shí)現(xiàn)服務(wù)層依賴(lài)于兩個(gè)技術(shù)選擇。第一個(gè)選擇就是那什么方法或者是調(diào)用來(lái)作為服務(wù)層的基礎(chǔ)。使用普通的類(lèi)還是服務(wù)？如果選擇服務(wù)，又該選擇哪種服務(wù)的實(shí)現(xiàn)技術(shù)？在Windows或者是.NET平臺(tái)，你的選擇比較少。你可以選擇WCF service、ASP.NET xml web service，或者是類(lèi)似于REST之類(lèi)的服務(wù)。

　　如果你對(duì)于.NET框架有一些了解，你應(yīng)該知道創(chuàng)建一個(gè)WCF service或者是web service，就好像創(chuàng)建普通的類(lèi)，然后添加一些attribute。當(dāng)然，還有很多細(xì)節(jié)需要考慮，例如：web service的WSDL（web service description language）web服務(wù)描述語(yǔ)言，WCF的配置和數(shù)據(jù)協(xié)議。服務(wù)最終是一個(gè)包含其他內(nèi)容的類(lèi)。

　　設(shè)計(jì)服務(wù)層的類(lèi)

　　服務(wù)層使用的類(lèi)應(yīng)該暴露一個(gè)協(xié)議，無(wú)論是WCF的協(xié)議還是實(shí)現(xiàn)接口。實(shí)現(xiàn)接口是一個(gè)比較好的做法，因?yàn)樗逦拿枋隽艘粋€(gè)類(lèi)可以做什么，將會(huì)做什么。接口使用DTO接收和返回?cái)?shù)據(jù)，推薦粗粒度的方法，以便它可以最小化網(wǎng)絡(luò)傳輸，最大化網(wǎng)絡(luò)吞吐量。

　　如何將需要的方法映射為接口和類(lèi)呢？在用例的基礎(chǔ)上，列出一系列所需的方法，然后將他們分為邏輯組。每個(gè)組建立自己的服務(wù)或者是類(lèi)。

　　大多數(shù)情況，你的結(jié)果是問(wèn)題域的每個(gè)實(shí)體建立一個(gè)服務(wù)類(lèi)，OrderService，CustomerServcie等等。這些都是應(yīng)用需要的。但是，如果用戶(hù)的行為相對(duì)比較小，行為比較相似，這時(shí)候一個(gè)服務(wù)類(lèi)可能就夠用了。否則，一個(gè)單一的服務(wù)類(lèi)會(huì)迅速變大，會(huì)很難以維護(hù)和變化。

　　通常來(lái)說(shuō)，我們認(rèn)為沒(méi)有嚴(yán)格定義的的準(zhǔn)則，例如：每個(gè)實(shí)體都要有自己的service，或者是一個(gè)service需要滿(mǎn)足用戶(hù)所有實(shí)體。服務(wù)層在系統(tǒng)的表現(xiàn)層和其他部分之間進(jìn)行調(diào)節(jié)。服務(wù)層包括了粗粒度的服務(wù)（也是用例驅(qū)動(dòng)的），在他們的編程接口中，實(shí)現(xiàn)了用例。

　　服務(wù)層和系統(tǒng)的其他部分相比，是獨(dú)立的，對(duì)于表現(xiàn)層來(lái)說(shuō)只是一個(gè)調(diào)用內(nèi)部處理流程的接口。如果用例有變化，你很可能只是修改服務(wù)層而不用修改業(yè)務(wù)邏輯。在一個(gè)相對(duì)較大的應(yīng)用中，對(duì)于服務(wù)層的編程接口來(lái)說(shuō)，你應(yīng)該先看一下你的用例，然后使用通用的方法組織類(lèi)中的方法。

　　實(shí)現(xiàn)一個(gè)服務(wù)層的類(lèi)

　　我們推薦每個(gè)類(lèi)應(yīng)該實(shí)現(xiàn)一個(gè)接口。如果你選擇WCF，這是嚴(yán)格要求的，而且從整體上來(lái)講是一個(gè)好方法。

it知識(shí)庫(kù)：分層架構(gòu)中的服務(wù)層-服務(wù)層實(shí)戰(zhàn)，轉(zhuǎn)載需保留來(lái)源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。