JHipster VMs与DTO

Ste*_*omm 6 dto jhipster

我想更多地了解JHipster选择生成DTO的决定.我有几个问题.

  1. 为什么叫DTO?JHipster 3.6.0发行说明中描述了它可用于在这些对象上执行业务逻辑.如果这实际上是它的意图,那么它不仅是DTO(数据传输对象).它更多,在我看来是一个域对象.好吧,也许这也不是一个理想的术语,因为Domain Object也被解释为DTO,实体等的父术语.从DDD的角度来看,它也可能被称为Aggregate,因为它结合了多个域对象.

  2. 基于1.,我认为,目前DTO的脚手架不适合DTO组合多个实体的意图.在这种情况下,它与一个特定实体无关,因此不应在该实体的背景下生成.

  3. 我认为目前DTO的脚手架更适合JHipster的VM定义(View Models).如果您有一个具有大量关系的复杂实体,也许还有一些blob或clob数据,那么您不希望将所有数据提交给前端.您需要一个VM来切断UI不需要的依赖对象.这非常适合当前的DTO脚手架,因为关系仅由ID表示.这也是JHipster网站上为DTO所描述的内容.我认为这种描述已被弃用,非常适合虚拟机,但不适用于DTO.以下是JHipster网站的引用:

这些对象在域对象的顶部添加了一个额外的层,并专门针对REST层进行了调整

DTO和VM的概念是否未被完全考虑过,或者我是否缺少一些重要方面?

Ind*_*von 5

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

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

然而,我们在旧的 jhipster-app 中也遇到了“麻烦”,并与层和 DTO、VM 等进行了大量讨论。我们在 jhipster 引入 DTO 和 Mapstruct 的同时开始。在我们使用 Jhipster 的新项目中,我们总是删除所有 DTO 和 VM。首先:(托管)UserVM/DTO 内容,这非常令人困惑。这有几个原因:

我们的应用程序的服务器端从来没有虚拟机。在 jhipster 应用程序中,视图完全基于 javascript/Angular,视图模型必须存在。我们经常有其他使用 REST-API 的应用程序,但这些应用程序不是视图。因此,特别是在微服务架构中,我永远不会将 REST-API 中的某些内容称为“视图”甚至“视图模型”。因此,在没有用 Java 编写视图(使用 JSP 等)的应用程序中,您将永远不会在 Java 代码中找到术语“VM”。此外,可能有不同类型的视图(例如,角度网络应用程序、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。这使我们能够将所有 ADO 与 client-API-jar 一起发布,而无需添加任何特定的内部实体或域对象。由于 REST-API 和每个插件使用相同的 ADO(因此具有相同的描述和结构),因此开发人员不会感到困惑,并且面向资源的外部层与使用另一种业务逻辑而不仅仅是资源的内部层正确分离。基于。

属于内部层的所有其他内容(例如实体、派生实体、实体的子集或超集)大多是域对象。因此,我们因此从该内部层、业务逻辑等中删除了所有 VM 和 DTO。

总之:为了封装来自外部访问的内部(JPA)实体,我们使用 ADO,因为除了视图之外可能还有其他实体。这些 ADO 是 jhipster VM 和 DTO 的形式。但在公共 API 层内部,我们从不使用任何 DTO 或 VM 甚至 ADO,因为这些实体主要是域对象。