DTO

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

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

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

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

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

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

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

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

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