將DTO對象深入集成在代碼中是否是一種好的做法？

我正在構建一個相當大的應用程序，它使用DAO/DTO設計模式從數據庫中獲取數據。在應用程序中，特定的DTO已成爲整個項目中引用的「核心數據結構」。我想知道在整個項目中如何深度集成這個DTO是否是一種好的做法，或者我應該有一種轉換層，將DTO轉換爲非DTO對象？將DTO對象深入集成在代碼中是否是一種好的做法？

我可以看到有和沒有這個轉換層的原因。例如，如果我們有轉換層，那麼：1）DTO的劇烈變化可能會導致整個項目出錯，因此轉換層會將錯誤隔離到代碼中的單個點。 2）我可以將其他邏輯添加到核心數據結構中，因爲它是自動生成的，所以無法添加到DTO。然而，我也看到有一個轉換層的缺點：1）DTO轉換代碼必須保持一致，只要DTO改變。這增加了程序員必須注意的另一個步驟，因此更容易出錯。 2）這也會導致代碼重複，因爲大部分情況下，您正在複製DTO的訪問器。

最好的路線是什麼？ DTOs每個地方還是一個轉換層？那裏的任何人都可以引導我走向正確的方向嗎？

來源

2010-06-18 david torres

我認爲DTO是反模式的東西，這是從EJB 1.0持久性如此健談以至DTO需要減少網絡流量時的一個遺留問題。

現在我會說創建模型對象並在晚上睡覺。如果可以的話，讓它們不變，不用擔心DTO。

翻譯爲了建築純度而浪費CPU週期而沒有提供太多價值。

來源

2010-06-18 23:17:14 duffymo

感謝duffymo的回覆。對此，我真的非常感激。 – 2010-06-19 15:57:19

然後通過投票答覆並接受答案來表達您的讚賞。這就是這個網站的工作原理。我更喜歡你的感激之情。 – duffymo 2010-06-19 16:10:18

他只有1的代表，所以他不能upvote。在接受一個答案之前，你應該給他一個等待其他答案的機會。至少你可以解釋如何接受答案，而不是扯皮。這就是這個網站的工作原理 - 閱讀常見問題:) – BenV 2010-06-25 05:16:34

我想這個名字會放棄這個意圖：數據傳輸對象。數據傳輸。

DTO背後的想法是，您可以使用它們將您發送到域模型之外的數據封裝到另一個層中。你沒有公開你的邏輯，你只是發送一些數據。

如果您的域對象是DTO的，那麼您要麼將域邏輯公開在域模型之外，要麼將域邏輯保留在域對象以外的某個位置。或兩者。

我一直在項目，讓他們分開，我一直在一個項目，混合他們。我真的不能推薦混合它們。你的圖層開始混合，就像扎染。

來源

2011-04-22 03:01:32

將DTO對象深入集成在代碼中是否是一種好的做法？

回答

相關問題