Question

我喜欢jhipster实体生成器。我经常可以更改模型并重新生成所有实体。

我希望保留生成的内容并覆盖我的需求。

从角度来看，创建一个扩展默认实体服务来完成我的工作的新服务非常容易。

在Java方面，它更为复杂。例如，我将src / main / java / xxx / web / rest / xxxOverrideResource.java覆盖src / main / java / xxx / web / rest / xxxResource.java

我必须在xxxResource.java中评论@RestController。我试图给它一个与被覆盖的类不同的捆绑包名称，但这还不够：@RestController（“ xxxResource”）
在xxxOverrideResource.java中，我必须将所有@xxxMapping（）更改为不同的路径
在xxxOverrideResource.java中，我必须更改所有方法名称这使我可以保留CRUD UI和API，并使用另一个MappingPath重载它。

一些代码使其更直观。这是生成的xxxResource.java

/**
 * REST controller for managing WorldCommand.
 */
// Commented to prevent bean dupplicated error.
// @RestController
@RequestMapping("/api")
public class WorldCommandResource {
    private final WorldCommandService worldCommandService;

    public WorldCommandResource(WorldCommandService worldCommandService) {
        this.worldCommandService = worldCommandService;
    }

    @PutMapping("/world-commands")
    @Timed
    public ResponseEntity<WorldCommand> updateWorldCommand(@Valid @RequestBody WorldCommand worldCommand)
            throws URISyntaxException {
        log.debug("REST request to update WorldCommand : {}", worldCommand);
        ...
    }

这是我的重载版本：xxxOverrideResource.java

/**
 * REST controller for managing WorldCommand.
 */
@RestController("WorldCommandOverrideResource")
@RequestMapping("/api")
public class WorldCommandOverrideResource extends WorldCommandResource {
    private final WorldCommandOverrideService worldCommandService;

    public WorldCommandOverrideResource(WorldCommandOverrideService worldCommandService) {
        super(worldCommandService);
        log.warn("USING WorldCommandOResource");
        this.worldCommandService = worldCommandService;
    }

    @PutMapping("/world-commands-override")
    @Timed
    public ResponseEntity<WorldCommand> updateWorldCommandOverride(@Valid @RequestBody WorldCommand worldCommand)
            throws URISyntaxException {
        throw new RuntimeException("WorldCommand updating not allowed");
    }

在xxxResource被覆盖的情况下，很容易通过构造函数注入覆盖xxxService和xxxRepository。

我觉得我想得太过分了。由于它不是外部组件，而是来自生成器的代码，因此目的可能是使用该工具编写较少的代码，然后进行所需的更改。

此外，我担心这种压倒性的体系结构会阻止我在需要时创建抽象控制器。

您认为保留原始生成的代码是一个好习惯吗？还是我应该在生成的类中进行更改，并在重新生成实体时要格外小心？
您知道重写Spring控制器的更好方法吗？

Answer 1

您的方法看起来像此处所述的并行方法：https://www.youtube.com/watch?v=9WVpwIUEty0

我经常发现生成的REST API仅对后台管理数据有用，而且我通常编写一个完整的独立API，其中包含移动用户或最终用户使用的不同的端点，授权和DTO。因此，我认为覆盖REST控制器没有太大的价值，毕竟它们应该很薄，并且业务逻辑尽可能少。

您还必须考虑与生成的代码保持这种兼容性的时间。随着应用程序复杂性的增加，您可能需要重构代码并围绕功能包而不是技术包（存储库，REST控制器，服务等）组织代码。由于许多原因，生成代码的设置迟早会影响您的工作，因此我不会为没有实际业务价值的兼容性目标付出过多的努力，尤其是当您知道年度发布的主要版本可能会中断时这是因为生成器本身发生了变化，或者更可能是由于基础框架发生了变化。

Jhipster替代实体（保持存在+添加行为）

1 个答案: