本機 D T O

如果你有在關注我的同事 ThoughtBloggers，你就會知道，看起來 我的其中一個機器人保險絲燒掉了，澳洲的陽光顯然讓這些瑞典模型變得很脆弱。

Jon 對 資料傳輸物件感到厭煩，但 DTO 並不是壞東西，就像任何模式一樣，它們在特定情況下很有用。模式總是包含兩個部分：如何和何時。你需要的，不只是知道如何實作它們，還必須知道何時使用它們，以及何時讓它們保持原狀。

他的確有道理 - 雖然我只有在遠端介面的情況下討論它們，但我沒有在模式本身的撰寫中重申它們的遠端情況 - 我確實會遇到喜歡在非遠端情況下使用它們的人。所以，這是我的補救機會。

DTO 被稱為資料傳輸物件，因為它們的唯一目的是在昂貴的遠端呼叫中轉移資料。它們是實作遠端介面所需的粗粒度介面的其中一部分，以提升效能。你需要的，不只是在本地情況下不需要它們，它們實際上是有害的，因為粗粒度 API 更難使用，而且你必須執行所有將資料從你的網域或資料來源層移動到 DTO 的工作。

有些人主張它們是 服務層 API 的一部分，因為它們確保服務層用戶端不依賴於底層 網域模型。雖然這可能很方便，但我認為不值得花費所有資料對應的成本。正如我的貢獻者 Randy Stafford 在 P of EAA 中所說：「不要低估 [使用 DTO] 的成本.... 這是顯著的，而且很痛苦 - 可能僅次於物件關係對應的成本和痛苦」。

我聽過另一個論點是，如果你想要在稍後進行分發，可以使用它們。這種推測性的分發界線正是我在 第一法則 中所反對的。新增遠端界線會增加複雜性。因此，我會呼應 Randy 的建議「從一個可於本地呼叫的服務層開始，其方法簽章處理網域物件。在需要時（如果需要）新增遠端性，方法是在服務層上放置 遠端門面，或讓服務層物件實作遠端介面。」

在某些情況下，使用類似 DTO 的東西會很有用，例如當簡報層中的模型與底層網域模型之間有顯著的不匹配時。在這種情況下，建立簡報專用的門面/閘道，從網域模型進行對應，並提供一個對簡報很方便的介面，是有意義的。它與 簡報模型 很契合。我希望在新的卷中進一步討論這個主題。這樣做是有價值的，但只適用於有這種不匹配的畫面（在這種情況下，這不是額外的作業，因為你無論如何都必須在畫面中執行它）。

更新：Thibaut Barrère 提醒我本地 DTO 的另一個用途，即在多執行緒應用程式中，在隔離區之間進行通訊。處理多執行緒的一個好方法是將應用程式分割成隔離區域，每個區域只有一個執行緒在執行。這消除了在該區域內並行控制的需求。如果你需要在這些隔離區域之間進行通訊，請使用訊息佇列，並使用 DTO 作為訊息來傳輸資訊。