JPA實體和/ vs DTOs

Question

在這些情況下，幫助決定何時使用DTO以及何時使用實體的一般想法是什麼？

1. UI /服務器端java調用服務。它應該得到/發送實體還是DTO？
2. 調用服務的Web服務。服務是否應接受實體或DTO？

我喜歡讀書，圍繞通過實體代碼：

1. 簡單繞過，沒有需要映射到DTO的
2. 不需要額外的類
3. 關係到其他實體已經定義，所以不需要將相關的DTO合併成一個DTO
4. 只是POJOs

但是有關DTO的觀點認爲映射到實體更安全，因爲它是一個契約，實體可以更改爲任何形式，並且DTO將保持不變。例如，如實體具有字段名稱，並且DTO也具有字段名稱。稍後，如果需求發生變化，數據庫表發生更改，實體也可以更改，將名稱更改爲firstName和lastName。但是DTO仍然會有一個字段名，即firstName + lastName。

所以這裏是使用的DTO的優點的列表：從接受的DTO

DTO的我能想到的是利弊代碼的觀點

1. 向後兼容：
   1. 必須定義DTO類和映射（可能使用推土機）
   2. 程序員將ħ AVE分析時使用DTO和實體，我的意思傳遞DTO每一個方法是一個爛攤子
   3. 開銷實體轉化爲DTO的，反之亦然
   4. IM仍然不確定如何將一個一對多的關係映射它們。在JPA中，我們可以懶惰地初始化這個，但是當傳入DTO時，我應該初始化這個還是不是。簡而言之，DTO不具備延遲初始化代理，只包含值。

   請分享你的想法..

   謝謝！

   這裏有來自不同地方的

   pro dto一些報價：

   實體類作爲DTO 的再利用顯得凌亂。 類的公開API（包括公開的 方法的註釋）不再明確定義 合同的目的，它是 介紹。該類將以 方法結束，該方法僅在 該類被用作DTO時使用，而 某些方法僅在使用 作爲實體時纔會被使用 。關注點不會被 乾淨地分開，事情會更加緊密地耦合到 。對我來說這是一個 更重要的設計考慮 然後試圖保存在 創建的類文件的數量。

   pro entity：

   絕對不是！

   JPA實體映射到數據庫， 但它們不綁定到數據庫。 如果數據庫發生更改，則更改 映射，而不是對象。 對象保持不變。這就是整個點的 ！

Answer 1

我會去的，原因如下的DTO選項：

• 服務接口應該是數據庫的獨立的，在一個變化不應該總是需要在其他的變化。
• 您正在假設您的服務將始終由Java客戶端調用
• 當對象位於Web服務的其他位置時使用延遲加載操作效果不佳。

Answer 2

Pro DTO： 1. UI的大部分時間都需要某些屬性，這些屬性僅用於傳遞描述UI狀態的參數。該狀態不需要保持，因此不需要在實體上使用。
2.業務邏輯應該位於實體內或實體的助手類中。您不應該與UI /表示層或客戶端調用它分享。
3.實體變化有時不需要更改DTO，反之亦然。
4.更容易對UI服務中的DTO執行系統級驗證，因此在不應該時停止對業務服務的調用。
5.您可以在UI端正在接收DTO時自由地實現/使用其他驗證框架，而不是實體充滿來自UI的數據。
6. UI /表示層鬆散耦合。

下面是當使用DTO的樣品流：
UI - > MVC - >使用UI服務系統的驗證 - >業務代理 - >商業服務 - >堅持。