dto[數據傳輸對象]

數據傳輸對象（DTO)(Data Transfer Object)，是一種設計模式之間傳輸數據的軟體套用系統。數據傳輸目標往往是數據訪問對象從資料庫中檢索數據。數據傳輸對象與數據互動對象或數據訪問對象之間的差異是一個以不具有任何行為除了存儲和檢索的數據（訪問和存取器）。

概述

dto[數據傳輸對象]

在傳統的系統（企業JavaBeans）體系結構，數據傳輸目標服務的雙重目的：第一，他們圍繞這個問題，pre-ejb實體不是序列化的；其次，他們含蓄地定義一個組裝階段，所有要使用的數據的提取和整理到數據傳輸目標之前返回控制[表現層]；第三個原因是使用數據傳輸目標可能是某些套用層不應該能夠訪問底層的數據訪問對象，從而改變數據。

產生

設計一個分散式應用程式，為了滿足單個客戶端請求，對一個遠程接口發出了多個調用，而這些調用所增加的回響時間超出了可接受的程度。

影響因素

遠程調用

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

遠程調用（那些必須跨越網路的調用）速度緩慢。雖然許多遠程調用框架可以隱藏進行遠程調用的複雜性，但是它們不能消除發生通信所需的步驟。例如，必須先找到遠程對象位置，而且建立與遠程計算機的連線，然後才能將數據串列化為位元組流，然後可能進行加密，最後才能將其傳輸到遠程計算機。

接口設計

在設計對象接口時，好的做法是將大量信息隱藏在對象內，並提供一組細粒度方法來訪問和操作該信息。"細粒度"意味著每個方法都應該負責單個的、相當小的和基本的功能單位。此方法簡化了編程，並提供了對對象內部的更加抽象，從而增加了重用的可能性。必須根據以下事實對此進行平衡取捨：使用較細粒度的方法意味著需要調用更多的方法才能執行高級別的任務。通常，在同一進程內調用方法時，這些額外函式調用的開銷是可接受的；但是，在跨進程和網路邊界調用這些方法時，開銷可能變得難以接受。

避免遠程調用中固有的滯後時間問題的最佳方法是進行更少的調用，並讓每個調用傳遞更多的數據。做到這一點的一種方法是，使用長參數列表來聲明遠程方法。這樣，客戶端就可以在單個調用中將更多的信息傳遞給遠程組件。但是，這樣做會使針對此接口的編程容易出錯，因為程式很可能僅按調用語句中的位置來調用外部方法的參數。例如，如果遠程方法接受 10 個字元串參數，則開發人員很容易按錯誤順序傳遞參數。編譯器將無法檢測到這樣的錯誤。

長參數列表無助於從遠程調用向客戶端返回更多的信息，因為大多數的程式語言將方法調用的返回類型限制為單個參數。而巧合的是，在傳輸大多數數據時通常需要返回較多信息。例如，許多用戶接口傳輸少量的信息，卻希望返回大量結果數據。

考慮事項

DTO 是簡單對象，它不應該包含需要測試的任何業務邏輯。但是，確實需要測試每個 DTO 的數據聚合。每個 DTO 可能需要測試，也可能不需要，這取決於序列化機制。如果序列化是框架的一部分，則只需要測試一個 DTO。如果不是這樣，請使用一般的反射機制，這樣就不需要測試每個 DTO 的序列化。

DTO 還對遠程函式的可測試性有好處。通過使遠程方法的結果能夠在對象實例中使用，可以輕鬆地將此數據傳遞到測試模組，或將其與所需結果進行比較。

安全考慮

理想情況下，應該先篩選和驗證從不可靠的來源獲得的數據（如來自 Web 頁的用戶輸入），然後將其置於 DTO 中。通過這樣做，就可以認為 DTO 中的數據是相對安全的，從而簡化了將來與 DTO 的互動。

接收 DTO 的進程和關聯用戶的安全憑據也是值得注意的。DTO 通常包含從許多不同來源聚集在一起的大量信息。是否已授權 DTO 的所有用戶訪問 DTO 所包含的所有信息？確保用戶已得到授權的最佳方法是僅使用用戶安全憑據所允許的特定數據填充 DTO。努力避免讓 DTO 負責自己的安全性。這將增加 DTO 對其他類的依賴數，這意味著必須將這些類部署到使用 DTO 的所有節點。這還會將安全性功能分散到更多類中，從而增大了安全風險，並對靈活性和可維護性產生負面影響。