何時在MVC4應用程序中使用DTO（數據傳輸對象）？

我讀過很多關於僅在需要時才使用模式的信息。我目前正在編寫一個非常簡單的應用程序，它實現了存儲庫和服務模式 - 我正在辯論是否將我的域對象傳遞給使用DTO的視圖。這是一個單頁面應用程序。何時在MVC4應用程序中使用DTO（數據傳輸對象）？

我開始在我的模型中創建DTO類，但仍不明白它們提供了哪些好處。感覺就像我無緣無故地複製了一切。

何時適合使用DTO？它在什麼時候變得必要或有益？任何示例/樣本都會很棒。

2013-03-01 RobVious

鏈接的問題不是這個問題的重複。這一個是關於在DTO或域對象（模型）之間進行選擇的，而關聯的問題是關於DTO的。 – Arashsoft 2016-01-28 14:20:57

我開始在我的模型中創建DTO類，但仍不明白它們提供了哪些好處。

那麼在這種情況下很可能會出現這樣的情況，即它們不提供益處。堅持最簡單的方法總是最好的，所以你可能會試圖不必要地增加複雜性。

我會說，當你只需要傳遞一些平面數據而不需要複雜的域對象時，DTO就很有用。在我看來，如果可能的話，最好是將您的視圖直接綁定到您的業務對象。如果沒有其他的，它提供了一個健全的檢查，你的業務對象符合你的使用場景。事實上，這是the CSLA framework（其中包括）着重於業務對象的方法。

最常見的情況，我發現自己翻譯域對象到DTO的是：

當我有一個外部服務的抽象依賴（這本身不符合我的內部域對象對齊）和我希望使服務接口本身非常簡單。我沒有在服務層做所有的翻譯，而是使用DTO本身並在兩者之間建立翻譯層。
當我通過AJAX調用將序列化對象返回給JavaScript時，並且不希望我的域對象的所有額外開銷都通過線路傳遞。保持JavaScript本身更簡單，不通過外部網絡連接傳輸不必要的數據等。
當我有一個視圖使用各種域對象數據的組合，但不是其超集。在某些情況下，這可能表明這個視圖表示一個用例，它有利於它自己的域對象（可能是其他對象的組合，或者所涉及的所有對象應該是較小的非聚合根對象的組合），所以要小心這種情況。但有時只是製作一箇中間的DTO可以讓代碼更簡單，更簡潔。

我認爲關鍵在於從一種形狀的數據轉換到另一種形狀。如果在服務，控制器或視圖中進行大量的翻譯...那麼也許這種翻譯是一個足夠大的組件，以適合自己的目標。這完全是關於分離問題，真的。一個好的經驗法則是，如果一段代碼「爲了達到某種目的而重新塑造數據和」，那麼這段代碼就是做了兩件事。將它分成兩段代碼可能會更好。 DTO是這兩個人如何溝通的。

有一些工具（如AutoMapper）可以幫助大量的「腳手架」代碼之間翻譯志趣相投的對象之間進行翻譯。

來源

2013-03-01 01:44:27 David

非常感謝大衛。在你使用DTO的情況下，你的Repository層是否可以處理？或者你會專門在服務層中使用一種方法來轉換對象（將GETTING與TRANSFORMING分開）？ – RobVious 2013-03-01 01:48:57

@RobVious：我沒有在我的倉庫中使用DTO，沒有。我傾向於認爲存儲庫基本上是一個用於保存和檢索域對象的工廠，最好是根對象（根據各種因素，它們可能會在內部延遲加載或急切加載其子對象）。一般來說，我的DTO儘可能接近我的代碼的邊界。（例如，僅用於視圖中或僅用於向外部供應商的後端Web服務調用。） – David 2013-03-01 01:52:29

非常感謝David的詳細信息。 – RobVious 2013-03-01 02:08:55

何時在MVC4應用程序中使用DTO（數據傳輸對象）？

回答

相關問題