當我們談論Java應用程序的開發時，數據傳輸對象被親切地稱爲DTO，是許多討論的主題。DTO誕生於Java世界中的EJB 2中有兩個目的。

首先，規避EJB序列化問題；其次，它們隱式定義了一個組裝階段，在該階段中，將要用於表示的所有數據在實際進入表示層之前都要進行封送處理。由於不再大規模使用EJB，是否還可以丟棄DTO？本文的目的是談談DTO的有用性並解決這個問題。

畢竟，在具有多個新主題的環境中（例如，雲和微服務），該層甚至有意義嗎？當涉及到良好的軟件體系結構時，答案實際上是一致的：這取決於您希望實體與可視化層耦合的緊密程度。

考慮分層的基礎架構，並將其自身分爲三個相互連接的部分，我們擁有著名的MVC。

值得注意的是，該策略並非像Spring MVC和JSF這樣的Web應用程序堆棧所獨有。將數據暴露在具有JSON的寧靜應用程序中，即使對典型數據不友好，JSON數據也可以可視化用戶。

簡要解釋了MVC之後，我們將討論使用DTO的優缺點。考慮到分層應用程序，DTO首先具有將模型與視圖分離的目的。關於DTO問題的思考：

增加複雜性

有重複代碼的可能性

添加新層會影響延遲層，即可能會導致性能損失。

在不需要豐富模型作爲前提的簡單系統中，不使用DTO可以爲應用程序帶來很多好處。有趣的一點是，許多序列化框架最終都迫使屬性具有始終存在且必須公開的訪問器，獲取器和設置器方法，因此，在某些時候，這將影響應用程序的封裝和安全性。

另一個選擇是添加DTO層，這基本上保證了視圖和模型的分離，如前所述。

它可以明確指出哪些字段將進入視圖層。是的，在各種框架中都有一些註釋，指示不會顯示哪些字段。但是，如果您忘記寫下來，則可能會意外導出關鍵字段，例如用戶密碼。

便於以面向對象的方式進行繪製。乾淨代碼清楚地說明了面向對象的要點之一是OOP隱藏了數據以暴露行爲，而封裝則對此有所幫助。

便於更新數據庫。在不影響客戶的情況下，重構，遷移數據庫通常是必不可少的。這種分離有助於優化和修改數據庫，而不會影響可視化。

版本控制，向後兼容性是重要的一點，尤其是當您擁有一個供公衆使用並有多個客戶的API時，因此可以爲每個版本都擁有一個DTO，並且無需擔心就可以發展業務模型。

另一個好處是易於使用豐富模型，並且創建了子彈批准的API 。例如，在我的模型中，我可以使用money API。但是，在我的可視化層中，我導出爲具有貨幣價值的簡單對象來進行可視化。那是Java中正確的舊String。

CQRS。是的，命令查詢職責隔離是否與寫和讀數據的職責分開有關，以及如何在沒有DTO的情況下做到這一點？

通常，添加一層意味着去耦並簡化維護，但要付出更多類和複雜性的代價，因爲我們還必須考慮這些層之間的轉換操作。例如，這就是存在MVC的原因，因此瞭解一切都基於影響和權衡或在給定應用程序或情況下的危害是非常重要的。

沒有這些層是非常糟糕的，它可能導致出現Highlander模式（只能有一個），其中有一個班級要承擔所有責任。同樣，多餘的層變成了洋蔥圖案，顯影劑穿過每一層時都會在此處哭泣。

相關文章