在一個理想的層級專案中，展現層是不能直接訪問領域物件的，那麼展現層如何獲取到自己需要的資料呢？也就是今天的主角-Application層，它的職責就是為展現層服務，它通過倉儲獲取到相應的資料，然後將資料以Dto的形式傳給展現層，負責展示。
那麼問題來了：1.什麼是Dto？2.Dto的好處是什麼？
一.Dto
Dto (Data Transfer Object):資料轉換物件，也就是用來傳遞資料用的。
Dto的好處：
1.在EF的CodeFirst的Model中，我們經常會使用導航屬性，但是使用導航屬性，帶來方便的同時，經常會遇到將資料序列化的問題，也就是物件迴圈序列化的死迴圈中。這就是直接使用Model作為展現層資料傳輸媒介帶來的問題。所以我們可以使用Dto來避免。
2.Model中的資料就是資料庫中的具體的欄位，然而我們可能只是使用其中的很少一部分的資料用於前臺的展示，所以使用Dto可以根據我們自己的需要減少傳遞的資料量，起到一定的保密性。
3.ABP框架中已經實現了一些現有的Dto，可以方便我們的開發，同時支援Dto的驗證，提高資料的安全性。
4.說到底，Dto最大的好處就是靈活，可以根據自己的需要靈活的擴充套件，不影響與資料庫的操作。起到了一定的解耦分離的作用。
在ABP框架中提供了很多方便我們開發的Dto,關於Dto的資料驗證，將在接下來的“電影票系統”的增刪改中具體的實踐，今天主要是針對的“查”，先展現出來看看再說。
二 .Application層的具體操作
我們自己的應用服務層的程式碼建立在哪裡呢，當然是ABP模板中為我們建立的Application中啊，嘿嘿
上面就是ABP模板為我們自動建立的Configuratrion功能的相關檔案，我們按照上面的模式，建立出我們自己的Dto資料夾，AppService 和介面。需要的注意，這裡我們自己定義的服務層的介面和實現類的字尾名都是以AppService介面為結尾的，這是ABP框架中的約定，至於為什麼要這樣，肯定是ABP中有很多的操作都是按照這個約定實現的，所以我們只需要按照約定辦事就好了。
1.首先建立出我的目錄結構
2. 前面的說過，一定要按照約定，以AppService命名結尾
Service
IService
Dto
Dto這邊需要注意兩點：
1.一定要定義Mapper的對映規則，此處採用的是特性標籤的方式定義對映規則。
2.前面已經說過ABP中提供了很多的現成的Dto可以簡化我們的操作，上面的EntityDto裡面定義了一個Id屬性，同時EntityDto還提供了泛型的支援，滿足對不同型別的Id的支援。
至於展現層，這裡我直接模仿程式碼模板中的樣式，稍微修改一下（先偷個懶）
這個父類繼承了AbpController，AbpController重寫了MVC的Controller的一些東西，同時提供了一些常用的屬性注入，比如AbpSession等
從上面的程式碼中可以看出，我們的控制器也是支援注入的，而且也是臨時的，及時銷燬的.
接下來我們就跑一下看看，能不能展示出來呢
我們定義的Service在Controller中沒有注入進來，為什麼沒有注入進來呢？喜聞樂見，這就是沒有按照約定辦事的結果。。。。。。這裡我們對MovieTicketAppService的命名重新更正。
再次執行一下，哈哈哈，出來了！
三.應用服務層的三個注意點
1.一定要實現介面IApplicationService，一定要按照約定來命名自己的Service，這是確保可以依賴注入的關鍵。
2.ApplicationService也是採用的UnitOfWork的模式，這個跟倉儲那邊是類似的。就是在一個服務方法中，共用一個資料庫連線，共用一個事務，當方法結束時，提交事務同時關閉資料庫的連線。
3.應用服務層注入的例項也是臨時性的，這個在上面的程式碼中可以看出，IApplicationService繼承自ITransientDenpency。
其實還有一個問題沒有詳細的介紹，既然我們有Dto用來為展現層提供資料，那麼我們的Model是如何轉換為Dto的呢？哈哈哈，這個簡單，不就是屬性賦值嘛，我一個個給Dto賦值。。。嗯，沒毛病。我上面使用了一種簡單的方法，那就是AutoMapper，自動實現對映，這個將在下一篇稍微研究一下。