今天談談《建構應用層服務》。
應用服務提供了一些門面樣式方法來分離表現層和領域層。這樣做的目的也是為了解耦，以後表現層就不用直接和業務邏輯層（核心層）打交道了，而是通過應用服務層（相當于媒介）來處理。應用服務層不僅定義了很多服務方法供表現層直接調用，而且還提供了一些Dtos(Data Transfer Object)。
第一，可以将它了解為一個簡化的實體，更友善。比如，我們有一個User表，裡面有Id,Name,Password,IsDeleted,CreationTime等等。那麼我們簡化的UserDto對象就隻含有Name和IsDeleted兩個字段就夠用了，因為表現層就隻用到了這兩個字段。
第二，更安全，性能更好。如果不用Dto而用實體類的話，最後生成的查詢就會将實體的所有字段都會查詢出來。這樣一來就暴露了一些重要的資料給一些我們不想這些資料被看到的人。
第三，應用擴充性更好，耦合度降低。表現層是通過一個Dto對象作為參數來調用應用服務方法的，然後使用領域對象（實體類對象）執行特定的業務邏輯并傳回一個Dto對象給表現層，是以，表現層完全獨立于領域層。在一個理想的應用中，表現層和領域層不會直接打交道。
第四，序列化問題。當傳回一個資料對象到表現層時，很可能會在某個地方序列化。比如，在一個傳回JSON的MVC方法中，你的對象可能會被序列化成Json發送到用戶端。如果傳回一個實體的話會有問題的。比如，這個User實體有一個Role的應用，如果要序列化User的話也會序列化Role。甚至Role可能有List<Permission>,Permission又有一個PermissionGroup的引用等等…你敢想象序列化之後的對象嗎？亦可以輕易地一下子序列化整個資料庫。是以，在這種情況下傳回一個安全序列化的、特别設計的DTOs是一個好的做法。
先來定義Dtos，看下面代碼：
這個是輸入方向的Dto，實作了IInputDto接口，這樣的話ABP可以自動幫助我們進行資料校驗。當然，我們也可以添加資料注解進行校驗。校驗之後，還可以實作IShouldNormalize接口來設定預設值。
以上是輸出方向的Dto。
接下來我定義一個城市表的服務接口ICityAppService，我的命名規範是”I+實體類單數+AppService”。
以上定義的方法有同步和異步兩個版本。
接下來實作應用服務接口，這裡隻實作一個方法GetCities(…)，望讀者舉一反三。
這裡又出現了個新東西AutoMapper，關于這個的使用，我這幾天會專門開一個關于AutoMapper的專題，敬請期待。代碼沒有難度，也就不多做解釋了。今天就到這裡吧。下次再講。
本文轉自tkbSimplest部落格園部落格，原文連結：http://www.cnblogs.com/farb/p/4930968.html，如需轉載請自行聯系原作者