与jHipster的构图关系

时间:2018-08-19 14:06:47

标签: jhipster aggregation composition

我正在学习jHipster。我的实体关系模型包含项目和文件。一个项目可以有零到多个文件,并且一个文件始终完全属于一个项目。

project <(1:1)-----(0:*)> file

用户与应用程序进行交互的方式类似于使用IDE。首先,打开初始网站后,他们总是必须选择要处理的项目。(当然,他们还可以创建新项目,或者删除旧项目。)只有这样,他们才能访问添加到特定项目的所有资源。项目,例如文件。

因此,我的REST API在逻辑上应该看起来像这样(以获取单个文件):

GET /projects/{:projectId}/files/{:fileId}

在后端,根据fileId是否为UUID,我什至可以拥有一个方法:

findFileByIdAndProjectId(String fileId, String projectId)

问题在于jHipster以“统一方式”创建所有实体。每个实体似乎都有其自己的不带嵌套的REST API,并且仅引用了另一个实体而不是适当的组成。调整生成的代码需要花费很多时间,因为它需要在前端和后端进行大量更改,但更重要的是,它可能会破坏实体更改后重新创建代码的能力。

我很好奇:我有什么不同的选择,你们会推荐哪个?

1 个答案:

答案 0 :(得分:1)

尽管有一些技巧可以帮助您:

  • 使用DTO,以便您可以在服务层中聚合实体
  • 在后端和前端都扩展生成的类,以免更改生成的代码,请参阅Antonio Goncalves的excellent talkslidescode samples