DTO(音樂團隊)

DTO是dream take off英文單詞的縮寫，代表意思為“夢想起飛”。正如熱愛音樂的DTO團隊的熱血青年一般，帶著自己的夢想向著未來前進，一同為音樂而奮鬥。DTO也是一款軟體套用的縮寫，Data Transfer Object。

基本介紹

• 中文名：夢想起飛
• 外文名：dream take off
• 英文縮寫：DTO
• 時間：2013年

音樂團隊

中國網路原創音樂DTO團隊；成立於2013年3月9日，匯聚全國各地眾多音樂愛好者加入，團隊共二十一人，團長俊懿，在詞曲、編曲、演唱、混音方面取得了優異的成績。代表作品有《殘破》、《邪惡吉他》《Darry Ring》《獨傷》等。

團長：俊懿

副團：汐雪、薛凌

詞曲部：阿浩、青雲、火昱、黃柯、易爵

編曲部：龍歡

歌手部：許磊、呆呆、清瑤

外交部：莫希

接待部：婉兒

軟體優缺

優點

減少了遠程調用次數。通過在單個遠程調用中傳輸更多的數據，應用程式可以減少遠程調用次數。

提高了性能。遠程調用可以使應用程式的運行速度大大降低。減少調用次數是提高性能的最佳方法之一。在大多數方案中，傳輸大量數據的遠程調用所用的時間與僅傳輸少量數據的調用所用的時間幾乎相等。

隱藏內部情況。在單個調用中來回傳遞更多的數據，還可以更有效地將遠程應用程式的內部情況隱藏在粗粒度接口的背後。這就是使用 Remote Facade 模式 [Fowler03] 的主要原因。

發現業務對象。在一些情況下，定義 DTO 有助於發現有意義的業務對象。在創建用作 DTO 的自定義類時，您通常會注意到作為一組凝聚性信息而顯示給用戶或另一個系統的元素分組。通常，這些分組用作描述應用程式所處理的業務域的對象的有用原型。

可測試性。將所有參數封裝到可序列化對象中可以提高可測試性。例如，可以從 XML 檔案中讀取 DTO，並調用遠程函式以測試它們。同樣，可以輕鬆地將結果再序列化為 XML 格式，並將 XML 文檔與所需結果進行比較，而不必創建冗長的比較腳本。

缺點

可能需要太多的類。如果選擇了使用強類型的 DTO，則可能必須為每個遠程方法創建一個（如果考慮返回值，則為兩個）DTO。即使在粗粒度接口中，這也可能導致大量的類。編寫如此數量的類的代碼並管理這些類會是很困難的。使用自動代碼生成可以在一定程度上緩解此問題。

增加計算量。如果將伺服器上的一種數據格式轉換為可以跨網路傳輸的位元組流，並在客戶端應用程式內轉換回對象格式，可以帶來相當大的開銷。通常，需要將來自多個源的數據聚合到伺服器上的單個 DTO 中。要提高通過網路進行遠程調用的效率，必須在任一端執行其他計算，才能聚合和串列化信息。

增加編碼工作量。可以用一行代碼完成將參數傳遞到方法的操作。使用 DTO 要求實例化新對象，並為每個參數調用 setters 和 getters。編寫此代碼可能是很乏味的。

java

影響因素

DTO與DAO的問題，在與遠程對象通信時，請考慮下列需要權衡的因素：

" 在考慮網路性能時，必須同時考慮滯後時間和吞吐量。簡單地說，"滯後時間"描述了數據的首位元組到達目的地之前所經過的時間。"吞吐量"描述了在某個時間段（例如 1 秒）內通過網路傳送的數據位元組數。在基於 IP 路由的現代網路（例如 Internet）中，滯後時間可以是比吞吐量更大的因素。這意味著，傳輸 10 位元組數據所用的時間可能幾乎等於傳輸 1,000 位元組數據所用的時間。在使用無連線協定（如 HTTP）時，此效果尤其明顯。通常，網路速度越快可以使吞吐量得以增加，但是，要減少滯後時間則會更加困難。

解決方案

MartinFowler在Patterns of Enterprise Application Architecture [Fowler03] 中對此模式進行了說明。

下圖顯示客戶端應用程式如何進行一系列遠程調用以檢索客戶名稱的各個元素。

DTO 允許遠程對象在單個遠程調用中將整個客戶名稱返回給客戶端。在此示例中，這樣做將使調用次數從 4 次減為 1 次。客戶端進行單個調用，然後在本地與 DTO 互動，而不用進行多次遠程調用（見圖 2）。

DTO 是一組需要跨進程或網路邊界傳輸的聚合數據的簡單容器。它不應該包含業務邏輯，並將其行為限制為諸如內部一致性檢查和基本驗證之類的活動。注意，不要因實現這些方法而導致 DTO 依賴於任何新類。

在設計數據傳輸對象時，您有兩種主要選擇：使用一般集合；或使用顯式的 getter 和 setter 方法創建自定義對象。

一般集合的優點是，只需要一個類，就可以在整個應用程式中滿足任何數據傳輸目的。此外，集合類（例如，簡單數組或散列圖）內置於幾乎所有語言庫中，因此您根本不必編寫新類的代碼。對 DTO 使用集合對象的主要缺點是，客戶端必須按位置序號（在簡單數組的情況下）或元素名稱（在鍵控集合的情況下）訪問集合內的欄位。此外，集合存儲的是同一類型（通常是最一般的 Object 類型）的項目，這可以導致在編譯時無法檢測到的微妙但致命的編碼錯誤。

如果為每個 DTO 創建自定義類，則可以提供與任何其他對象完全一樣的、客戶端應用程式可訪問的強類型對象，這樣的對象可以提供編譯時檢查，並支持代碼編輯器功能（如 Microsoft® IntelliSense® 技術）。主要缺點是，如果應用程式發出許多遠程調用，則您最終可能必須編寫大量類的代碼。

許多方法試圖將這兩種方法的優點結合在一起。第一種方法是代碼生成技術，該技術可以生成脫離現有元數據（如可擴展標記語言 (XML) 架構）的自定義 DTO 類的原始碼。第二種方法是提供更強大的集合，儘管它是一般的集合，但它將關係和數據類型信息與原始數據存儲在一起。Microsoft DataSet 支持這兩種方法

有了 DTO 類以後，需要用數據填充它。大多數情況下，DTO 內的數據來自多個域對象。因為 DTO 沒有行為，因此它不能從域對象提取數據。這是對的，因為如果讓 DTO 不知道域對象，您就可以在不同的上下文中重用 DTO。同樣，您不希望域對象知道 DTO，因為這可能意味著更改 DTO 將要求更改域邏輯中的代碼，這將導致大量維護任務。

最佳的解決方案是使用 Assembler 模式 [Fowler03]，該模式可以用業務對象創建 DTO 或者相反。Assembler 是 Mapper 模式的專門實例，在 Patterns of Enterprise Application Architecture [Fowler03] 中也提到過它。

Assembler 的關鍵特徵是 DTO 和域對象不相互依賴。這就消除了這兩種對象的相互影響。不利方面是 Assembler 同時依賴於 DTO 和域對象。對這些類的任何更改都可能導致必須更改 Assembler 類。