我想更多地了解JHipster选择生成DTO的决定。我有几个问题。
为什么叫DTO？在release notes of JHipster 3.6.0中描述了它可用于在这些对象上执行业务逻辑。如果这实际上是它的意图，那么它不仅是DTO（数据传输对象）。它更多，在我看来是一个域对象。好吧，也许这也不是一个理想的术语，因为Domain Object也被解释为DTO，实体等的父术语。从DDD的角度来看，它也可能被称为Aggregate，因为它结合了多个域对象。
基于1.我认为，目前DTO的脚手架并不适合DTO组合多个实体的意图。在这种情况下，它不会与一个特定实体相关，因此不应该在该实体的上下文中生成。
我认为目前DTO的脚手架更适合JHipster的VM定义（View Models）。如果你有一个复杂的实体，有很多关系，也许还有一些blob或clob数据，你不想把所有数据都提交给前端。您需要一个VM来切断UI不需要的依赖对象。这非常适合当前的DTO脚手架，因为关系仅由ID表示。这也是JHipster网站上DTOs所描述的内容。我认为这种描述已被弃用，非常适合虚拟机，但不适用于DTO。以下是JHipster网站的引用：
这些对象在域对象的顶部添加了一个额外的图层，并专门针对REST图层进行了调整
DTO和VM的概念是否未被完全考虑过，或者我是否遗漏了一些重要方面？
答案 0 :(得分：3)
虽然我不能说为什么团队决定，我绝对同意DTO / VM概念不是很清楚。
我认为，基本思想类似于MVP / MVC模式，通常会引入新的视图模型来获取MVVM模式。因此，不影响任何视图的DTO被“推送”到实际的模型/控制器层中。如果你说DTO是服务之间的传输对象，那也没关系。
然而，在我们的旧款jhipster-app中，我们也遇到了“麻烦”以及与层和DTO，VM等的大量讨论。我们在jhipster介绍DTO和Mapstruct的同时开始了。在我们使用Jhipster的新项目中，我们总是删除所有DTO和VM。首先：（托管）UserVM / DTO的东西，这是非常令人困惑的。这有几个原因：
我们的应用程序的服务器端永远不会有VM。在jhipster应用程序中，视图完全基于javascript / angular，视图模型必须在那里。我们经常有其他使用REST-API的应用程序，这些应用程序不是视图。因此，特别是在微服务架构中，我永远不会在REST-API“视图”甚至“视图模型”中调用某些东西。 因此，在没有用Java编写视图的应用程序中（使用JSP等），您将永远不会在我们的Java代码中找到术语“VM”。此外，可能存在不同类型的视图（例如，角度web应用程序，iOS应用程序，桌面客户端或其他东西），并且它们中的每一个都具有其他视图，视图部件，小部件，因此需要其他视图模型。最后，有些人说REST-API可能不提供任何不是真正的资源/实体的东西...
所以，你绝对正确的是，jhipster中的虚拟机实际上是DTO。但是，正如您所说，“DTO”存在问题，因为通常DTO只是一个无状态传输对象，可以在没有任何逻辑的情况下在两个或多个服务（或系统）之间封装公共值。我们认为这也是自上而下（REST）API驱动和自下而上的域驱动设计之间的架构问题，它们在JHipster应用程序中以某种方式混合。与您的观点相似，我认为JHipster使用DTO，它应该是域对象（或实体）。例如。托管用户不是VM或DTO，而是实体。我认为，这里的问题是有些人认为只有基于JPA的实体是域对象，并且可能没有其他域对象（实体）。
最后，我们决定引入一种名为ADO（API数据对象或访问数据对象）的新类型，因为我们找不到适合的术语。将ADO与jhipster，VM，DTO或甚至没有任何逻辑的实体进行比较。常见的“API层”仅读取和写入ADO。该层用于REST API控制器以及插件可以使用的Java API。这使我们可以使用客户端API-jar发布所有ADO，而无需添加任何特定的内部实体或域对象。由于REST-API和每个插件使用相同的ADO（因此具有相同的描述和结构），因此开发人员不会混淆，并且外部面向资源的层与使用其他业务逻辑的内部层正确分离，而不仅仅是资源 - 根据。
作为实体，派生实体，子集或实体超集的内部层的其他所有内容主要是域对象。因此，我们从此内部层，业务逻辑等中删除了所有VM和DTO。
总之：要从外部访问封装内部（JPA）实体，我们使用ADO，因为除了视图之外可能还有其他实体。这些ADO就jhipster VM和DTO而言。但是在公共API层的内部，我们从不使用任何DTO或VM甚至ADO，因为这些实体主要是域对象。