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，因为这些实体主要是域对象。