DTO產生背景
當我們在設計面向對象接口的時候，好的實踐是在一個對象中隱藏很多信息，並提供一組細粒度的方法來訪問和操作這些信息，這意味着每個方法都應該負責單個、細粒度的、原子化的功能。這種方法從對象內部提供了很好的抽象，並增加了方法重用的可能性，這樣做需要寫很多的方法。
通常情況下，按照上述實現方式，執行復雜任務時可能會調用很多的方法，這在同一個進程中這些方法的開銷是可以接受的。但是跨進程或者跨網絡調用時，開銷會變得很嚴重。
當客戶端爲獲取多個數據而向服務器發送多次請求，這會嚴重影響應用的性能。可以發送一次請求到服務器來檢索當前需要的所有數據，這樣做大大提高了性能，而當前需要的所有數據稱之爲數據傳輸對象(DTO)
簡介
dto–data transfer object–數據傳輸對象，字面意思就是一個對象，一個類，這個類包含我們需要的信息（屬性）
dto通常用於展現層（Presentation Layer）和應用層（Application Layer）之間相互傳遞數據。
展現層調用應用層的方法，傳遞dto參數到應用層，應用層將dto進行必要的處理轉化成entity交給領域層執行具體的業務邏輯。
應用層根據展現層需要的數據返回dto給展現層。
優點
1 將領域層抽象
dto提供一種有效的方式將領域對象從展現層抽象化，使展現層和領域層徹底解耦，沒有任何相互依賴。
如果徹底修改展現層，仍然可以繼續使用已經存在的應用層和領域層。
如果修改了領域層，該變數據庫，改變OR/M 框架，這些改動不會對展現層造成太多影響。
2 數據隱藏
dto中字段有很多會和entity中字段一樣，爲什麼不直接用entity呢？因爲使用dto更安全更輕量。
a)如何返回entity給展現層，展現層實際上不需要一個完整entity的所有信息，這樣做會泄漏entity的信息。
比如只需要一個User的基本信息，但不包含密碼和年齡，返回entity會將這些信息泄漏，外層就可以修改，這樣就不安全！
2）entity之間會存在一些關聯屬性，比如一個User有某個Role引用，某個Role有Permission引用。幾乎所有的O/RM框架都支持懶加載，返回用戶信息極有可能會返回用戶、角色、權限這些所有的信息，而這些信息大多是不需要的。
3 序列化問題
展現層將數據返回UI時一般會將dto序列化再返回,
當使用entity時，並且entity中存在一些循環引用，這個時候序列化會失敗。
dto設計原則
1.不應該包含任何業務邏輯
2.不應和enity有任何依賴
3.dto作爲 輸入 時，不應該包含不需要的屬性，否則會給開發人員造成困惑。
4.dto作爲 輸入 時， 不應該在不同的應用服務（ApplicationService）中使用同一個dto，因爲不同的應用服務可能需要不同的屬性。如果不同的應用服務在輸入時使用相同的dto，會造成dto中出現空屬性，這會造成應用服務理解起來更復雜，並可能在未來引發一些bug。
5.dto作爲輸出時並且所有的屬性都已賦值，那麼可以在不同的應用服務中使用。