應用程序框架實戰(zhàn)三十五:服務概述

　　上一篇介紹了我對幾種實體的認識，本篇將介紹幾種服務的用法。

　　預告一下本系列后續(xù)計劃，本篇之后，準備進入實戰(zhàn)演練階段，先介紹如何快速解決CRUD操作，從如何使用PD數(shù)據(jù)建模到使用CodeSmith生成代碼，先帶你感受一下，再回過來介紹框架內(nèi)部元素，以免你在閱讀時昏昏欲睡。

應用服務介紹

　　對于一個新的設計元素，可以先假定不需要它，等到確實認識到它的作用再引入。那么，應用服務為我們帶來了哪些好處呢？

應用服務幫助簡化表現(xiàn)層操作

　　以MVC為例，如果沒有應用服務，那么控制器將直接調(diào)用倉儲，設置查詢條件，轉(zhuǎn)換DTO等。

　　當控制器操作變得復雜，你會想辦法把控制器代碼分離出去。分離控制器代碼的最好方法就是建立對應的應用服務，不要輕易的分離控制器本身，因為這會導致查找視圖變得困難，并且破壞了約定，導致更高的維護成本。

應用服務為表現(xiàn)層提供唯一的API訪問點

　　當一個控制器操作變得復雜時，編寫控制器的程序員需要了解更多的知識，這些操作是由哪些聚合、領域服務、基礎設施服務等構造元素組裝起來的呢，調(diào)用順序如何？

　　這是表現(xiàn)層應該關心的問題嗎？

　　表現(xiàn)層應該只關心界面展示，這是表現(xiàn)層的基本職責所在，其它職責盡量轉(zhuǎn)移到后方。

　　應用服務將細粒度操作打包為粗粒度操作，讓編寫表現(xiàn)層的程序員不再東張西望，他只需要記得一件事：需要訪問任何后端的操作，找應用服務就對了。

應用服務為多個表現(xiàn)層減少冗余代碼

　　如果需要多個表現(xiàn)層，比如需要開發(fā)一個WPF程序，功能與MVC完全一樣，這時候，你會發(fā)現(xiàn)表現(xiàn)層充斥大量重復代碼。

　　引入應用服務后，表現(xiàn)層代碼更簡潔，冗余代碼更少，創(chuàng)建多個表現(xiàn)層更加輕松。

應用服務集成和裝配領域?qū)优c基礎設施層

　　為了保持領域?qū)拥募儍?，我們采用依賴倒置原則，領域?qū)又粨碛胁僮鹘涌?，具體實現(xiàn)卻在基礎設施層，最終要能運行起來，必須將它們組裝到一起。

　　如果沒有應用服務，控制器將需要自己進行裝配，這增加了表現(xiàn)層的負擔，應用服務承接了這項工作，讓表現(xiàn)層專心干自己的本職工作。

應用服務配合DTO優(yōu)化遠程調(diào)用性能

　　當采用了分布式架構，為了提升性能，需要盡量減少遠程調(diào)用次數(shù)。

　　應用服務在分布式環(huán)境充當了遠程外觀，配合DTO一起解決這個問題。

應用服務與BLL的比較

　　對于長時間采用傳統(tǒng)三層架構的朋友，對于應用服務這個構造是無比的親切，初步用起來以后，你發(fā)現(xiàn)這個應用服務就是BLL的翻版。

　　BLL是傳統(tǒng)三層架構的業(yè)務邏輯層，很多人直接用BLL來命名業(yè)務邏輯層的服務類，我暫時就用這個稱呼。

　　BLL是業(yè)務邏輯放置的場所，BLL將結果保存到Model實體類中，然后將實體類傳遞給其它層。

　　應用服務用于協(xié)調(diào)領域?qū)优c基礎設施層的操作，應用服務本身不應該完成復雜的業(yè)務邏輯。

　　應用服務與BLL的關鍵區(qū)別在于，BLL直接完成業(yè)務邏輯，而應用服務會將業(yè)務邏輯委托給領域?qū)嶓w或領域服務。

　　從代碼上看，BLL主要通過操作Model的屬性進行業(yè)務邏輯的處理，而應用服務通過調(diào)用領域?qū)嶓w或領域服務的方法完成所有業(yè)務操作。

領域服務介紹

　　從前面的介紹，你應該已經(jīng)發(fā)現(xiàn)應用服務是有用的，下面再來看看領域服務。

　　在最理想的情況下，所有的業(yè)務邏輯都應該高度內(nèi)聚到聚合中。但對于更復雜的業(yè)務，一般都有比較復雜的流程，這些流程上的控制，放入聚合并不合適，因為這些行為不屬于某個聚合。

　　如果把這些行為放到應用服務中，可能導致應用服務非常復雜，業(yè)務邏輯也從領域?qū)用撾x出來，使業(yè)務邏輯的管理更加困難。

　　為了把業(yè)務邏輯重新移回領域?qū)?，需要添加一個領域服務。

　　現(xiàn)在我們有了應用服務和領域服務兩個構造元素，那么，對于一個復雜操作，應該將哪一部分放入應用服務，哪些又放到領域服務呢？

　　書上介紹，業(yè)務邏輯可分為領域邏輯和應用邏輯，領域邏輯應該完全放到領域?qū)樱荒苄孤兜狡渌鼘尤ィ鴳眠壿嫅摲诺綉脤臃铡?/span>

　　可以看出，說得相當抽象，哪種東西算得上領域邏輯，哪種又是應用邏輯？這個很難精確劃分。

　　一個經(jīng)典的應用邏輯例子是事務控制，事務控制不是客戶的需求，但卻非常重要，所以把這種東西放到應用層，而不是領域?qū)印?/span>

　　那么發(fā)郵件的操作是領域邏輯，還是應用邏輯？？有人說是領域邏輯，有人說是應用邏輯，還有人說要看情況?？芍^眾說紛紜，讓你摸不著頭腦。

　　不過我們學習的目的不是進行學術辯論，而是切實的提升項目可維護性，所以不用太理會那些考智商的概念，下面談談我的用法。

　　對于應用服務，我總是需要它，因為它可以簡化表現(xiàn)層開發(fā)。

　　對于某些比較簡單的業(yè)務邏輯，如果發(fā)現(xiàn)建立領域服務并未產(chǎn)生太大價值，我就直接放入應用服務中。比如判斷一個實體的名稱不能重復，這是一個業(yè)務需求，首先考慮這個業(yè)務邏輯可以放入實體中嗎？不能，因為實體本身無法了解自己的名稱有無重復。其次考慮需要建立領域服務嗎？對于這種簡單業(yè)務邏輯，創(chuàng)建一個領域服務有點大炮打蚊子的感覺。我會直接將重名檢測放入應用服務中，雖然導致有一點業(yè)務邏輯散落到應用層，但我未發(fā)現(xiàn)對可維護性造成影響。

　　如果業(yè)務邏輯比較復雜，我一般會采用TDD方式推進業(yè)務開發(fā)，這種情況下，建立領域服務是一個極好的選擇，因為領域?qū)右蕾嚨停?strong>單元測試更方便。

　　不論應用服務，還是領域服務，開發(fā)的基本原則是，盡量將業(yè)務邏輯委托給領域?qū)嶓w，服務僅做調(diào)度的工作。

　　基礎設施服務比較好理解，就是提供一些基礎支持服務，比如發(fā)送郵件等操作。

需要為服務抽取接口嗎

　　學習設計模式時，要求我們面向接口編程，但一些對象大師建議不要過度設計，以免導致不必要的復雜性，在《實現(xiàn)領域驅(qū)動設計》一書中提出，應用服務使用獨立接口沒有什么好處。

　　雖然接口有不少作用，但一般來講，驅(qū)動創(chuàng)建接口的真正需求來自多態(tài)。在一般的項目開發(fā)中，特別是前期，服務很少具有多態(tài)需求，那我們還要不要為服務建立接口?

　　在沒有使用Resharper的年代，我使用接口非常小心謹慎，因為從接口定位實現(xiàn)類非常困難，但自從用上了Resharper，接口不再成為障礙。

　　另一方面，IOC框架的使用，讓接口的使用進一步普及，我只需要將實現(xiàn)類綁定到接口，在程序中就可以自由使用了。雖然IOC可以直接綁定實現(xiàn)類，但總感覺有點奇怪。

　　最后，對于跨層訪問，采用接口互聯(lián)也符合分層設計原則。

　　對于采用了Ioc框架，并安裝了Resharper這樣強大的工具，接口不會給你造成任何不便，至于是否導致復雜性，則需要自己體會。

　　代碼中采用接口編程，可能在大多情況下都未產(chǎn)生實質(zhì)的好處，但在需求發(fā)生變化時，只需修改Ioc配置替換相關實現(xiàn)，這個擴展性在不花成本的情況下還是劃得來的。

服務命名約定

　　當同時需要應用服務和領域服務，會發(fā)現(xiàn)服務取名也很困難。比如用戶管理，應用服務叫UserService，如果需要領域服務，也叫UserService就發(fā)生沖突，但命名為其它可能又不合適。

　　我的辦法是應用服務統(tǒng)一以Service結尾，領域服務統(tǒng)一以Manager結尾，這樣就可以簡單的解決這個問題。對于和我一樣的英文菜鳥，可能特別有用。

何鎮(zhèn)汐的技術博客

Util框架--.Net應用程序框架