JHipster虛擬機與DTOs

Question

我想了解更多關於JHipster生成DTO選項的決定。我有幾個關於它的問題。

1. 爲什麼叫做DTO？它在release notes of JHipster 3.6.0中有描述，它可以用來在這些對象上執行業務邏輯。如果這實際上是它的意圖，那麼它不僅是一個DTO（數據傳輸對象）。更重要的是，它在我看來是一個域對象。好的，也許這也不是理想的術語，因爲域對象也被解釋爲DTO，實體等的父項。從DDD的角度來看，它也可以稱爲聚合，因爲它組合了多個域對象。

2. 基於1.，我認爲目前的DTO腳手架不適合DTOs結合多個實體的意圖。在這種情況下，它不會與某個特定實體相關，因此不應在該實體的情況下生成。

3. 我認爲目前的DTO腳手架更適合JHipster對VMs（視圖模型）的定義。如果你有一個複雜的實體有很多關係，也許還有一些blob或clob數據，你不想把所有的數據提交給前端。您需要一個VM來切斷UI不需要的依賴對象。這與當前的DTO腳手架非常吻合，因爲關係僅由ID表示。這也是JHipster網站上爲DTOs所描述的內容。我認爲這個描述已經被棄用，並且適用於虛擬機，但不適用於DTO。下面是從JHipster網站報價：

這些對象的域對象上添加一個額外層，並專門調整爲休息層

已DTO的概念虛擬機還沒有完全被認爲，或者我錯過了一些重要的方面？

Answer 1

雖然我不能說團隊爲什麼做出這個決定，但我絕對同意DTO/VM概念不是很清楚。

我認爲，其基本思想類似於MVP/MVC模式，其中通常引入一個新的視圖模型來獲得MVVM模式。因此，不影響任何視圖的DTO被「推入」實際的模型/控制器層。沒關係，如果你說DTO是服務之間的傳輸對象。

但是，我們在老jijers-app中也遇到了麻煩，並且與層和DTO，VM等進行了很多討論。我們在jhipster推出DTOs和Mapstruct的同時開始了這個工作。在我們使用Jhipster的新項目中，我們總是刪除所有DTO和VM。首先：（託管）UserVM/DTO的東西，這是非常混亂。這有幾個原因：

我們的應用程序的服務器端從來沒有虛擬機。在一個jijster應用程序中，視圖完全基於javascript/angular，視圖模型必須在那裏。我們經常有其他使用REST-API的應用程序，這些應用程序不是視圖。因此，特別是在微服務架構中，我從來不會在REST-API「視圖」甚至「視圖模型」中調用某些東西。 因此，在沒有用Java編寫視圖的應用程序中（使用JSP等），在我們的Java代碼中永遠不會找到術語「VM」。此外，可能存在不同類型的視圖（例如，角度web應用，iOS應用，桌面客戶端或其他事物），並且每個視圖都具有其他視圖，視圖部件，小部件並因此需要其他視圖模型。最後，有些人說REST-API可能不會提供任何不是真正的資源/實體的東西......

所以，你絕對正確的說jijter中的虛擬機實際上是DTO。但是，正如你所說，「DTO」存在一個問題，因爲通常DTO只是一個無狀態的傳輸對象，用於在沒有任何邏輯的情況下封裝兩個或多個服務（或系統）之間的公共值。我們認爲這也是自頂向下（REST）API驅動和自下而上的域驅動設計之間的架構問題，它們在JHipster應用程序中以某種方式混合。與你的意見類似，我認爲JHipster使用DTOs的地方它應該是一個域對象（或實體）。例如。受管理的用戶不是虛擬機或DTO，而是實體。我認爲，這裏的問題是有些人認爲只有基於JPA的實體纔是域對象，並且沒有其他域對象（實體）。最後，我們決定引入一個名爲ADO（API數據對象或訪問數據對象）的新類型，因爲我們沒有找到適合的術語。一個ADO與一個VM，一個DTO甚至一個沒有任何邏輯的實體進行比較。一個常見的「API層」只能讀取和寫入ADO。該層用於REST API控制器以及可供插件使用的Java API。這使我們有可能通過client-API-jar發佈所有ADO，而無需添加任何特定的內部實體或域對象。由於REST-API和每個插件使用相同的ADO（因此具有相同的描述和結構），因此開發人員不會感到困惑，並且外部面向資源的層與使用其他業務邏輯的內部層相比，根據。

其他所有內部層的一部分，如實體，派生實體，子集或實體超集大部分都是域對象。因此，我們從內部層中刪除了所有VM和DTO，業務邏輯等。總結：爲了封裝來自外部訪問的內部（JPA）實體，我們使用ADO，因爲除了視圖之外可能還有其他的。這些ADO是根據jtimester虛擬機和DTO的。但是在公共API層的內部，我們從不使用任何DTO或VM，甚至不使用ADO，因爲這些實體主要是域對象。