JHipster VMs与DTO

Question

我想进一步了解一下JHipster关于生成DTO的选择的决定。我对此有几个问题。

1. 为什么叫DTO？JHipster 3.6.0的发行说明中描述了它可以用于对这些对象执行业务逻辑。如果这实际上是它的意图，那么它不仅仅是一个DTO (数据传输对象)。更重要的是，在我看来，它是一个域对象。好的，也许这也不是一个理想的术语，因为域对象也被解释为DTO、实体等的父术语。从DDD的角度来看，它也可能被称为聚合，因为它结合了多个域对象。
2. 基于1.我认为，当前DTO的脚手架并不适合DTO合并多个实体的意图。在这种情况下，它不会与一个特定的实体相关，因此不应该在该实体的上下文中生成。
3. 我认为当前DTO的脚手架更适合JHipster对VM (View Models)的定义。如果你有一个复杂的实体，有很多关系，也许还有一些blob或lot数据，你不想把所有这些数据提交到前端。您需要一个VM来切断依赖对象，这些对象是UI所不需要的。这很适合当前的DTO脚手架，因为关系只由ID表示。这也是JHipster网站上对DTO的描述。我认为这种描述是不可取的，非常适合VM，但不再适合DTO。以下是JHipster网站的引文：

这些对象在域对象之上添加了一个额外的层，并专门为REST层进行了调优。

DTO和am的概念是否没有得到彻底的考虑，还是我遗漏了一些重要的方面？

Answer 1

虽然我不能说为什么这个决定是由团队做出的，但我绝对同意DTO/VM-的概念并不是很清楚。

我认为，基本思想与MVP/MVC模式类似，在MVP/MVC模式中经常引入一个新的视图模型来获得MVVM模式。因此，不影响任何视图的DTO被“推入”到实际的模型/控制器层。这是可以的，如果您说DTO是服务之间的传输对象。

然而，我们也遇到了“麻烦”，并在我们的老jhipster应用程序中与图层、DTO、VM等进行了大量讨论。我们在同一时间开始使用DTO和Mapstruct技术。在新的项目中，我们使用Jhipster，我们总是删除所有的DTO和VM。首先：(托管)UserVM/DTO内容，这是非常令人困惑的。这有几个原因：

我们的应用程序的服务器端从来没有VM。在一个完全基于javascript/angular的jhipster应用程序中，视图模型必须存在。我们经常有其他使用REST的应用程序，而这些应用程序不是视图。因此，特别是在微服务体系结构中，我永远不会将REST API中的东西称为“视图”甚至“视图模型”。因此，在没有用Java编写视图(使用JSP左右)的应用程序中，您将永远不会在Java代码中找到术语"VM“。此外，可能有不同类型的视图(例如角web应用程序、iOS应用程序、桌面客户端或其他东西)，而且每个视图都有其他视图、视图部件、小部件，因此需要其他视图模型。最后，有人说REST-API可能不会提供任何不是真正的资源/实体的东西.

所以，你是绝对正确的，在jhipster中的VM实际上是DTO。但是，正如您还提到的，" DTO“有一个问题，因为通常DTO只是一个无状态传输对象，用于封装两个或多个服务(或系统)之间的公共值，而没有任何逻辑。我们认为这也是自上而下(REST) API驱动的和自下而上的域驱动设计之间的架构问题，这两者在JHipster应用程序中是混合在一起的。与您的观点类似，我认为JHipster使用DTO，其中应该是域对象(或实体)。例如，托管用户不是VM或DTO，而是实体。我认为，这里的问题是，有些人认为只有基于JPA的实体是域对象，而不可能有其他域对象(实体)。

最后，我们决定引入一种名为ADO (API数据对象或访问数据对象)的新类型，因为我们没有找到合适的术语。ADO被比作一个VM，一个DTO，甚至一个没有任何逻辑的实体。普通的“API层”只读写ADO。这一层用于REST控制器以及可由插件使用的Java。这使我们可以在不添加任何特定的内部实体或域对象的情况下，将所有ADO与client一起发布。由于REST-API和每个插件使用相同的ADO(因此使用相同的描述和结构)，因此开发人员并不感到困惑，面向资源的外部层与使用其他业务逻辑的内部层(而不仅仅是基于资源的业务逻辑)正确地分开。

实体、派生实体、子集或超集等内部层的其他部分都主要是域对象。因此，我们从这个内部层、业务逻辑等中删除了所有VM和DTO。

总之:为了从外部访问封装内部(JPA)实体，我们使用ADO，因为可能有其他实体而不仅仅是视图。这些ADO包括jhipster和DTO。但是在公共API层的内部，我们从不使用任何DTO或VM，甚至是ADO，因为这些实体大多是域对象。