代表设计模式在Swagger生成代码中的java意义？

Question

当我从我的swagger yaml为Spring生成代码时，通常使用delegate模式生成控制器层，这样对于一个模型会生成三个文件。例如，如果我在swagger/open API yaml文件中定义了一个名为Person的模型，则会生成三个文件：

1. PersonApi (interface that contains signatures of all person operations/methods)
2. PersonApiDelegate ( interface that provides default implementation of all PersonApi methods . Meant to be overriden )
3. PersonApiController (Which has a reference to PersonApiDelegate so that any implementation can override and provide custom implementation)

我的问题是，对于任何熟悉构建swagger/openapi生成的基于代码的API的人来说，拥有这样一种模式的意义是什么，而不仅仅是使用PersonControl类公开服务端点，而不是先通过PersonApi接口，然后再通过PersonApiDelegate，最后通过PersonApiController公开服务

我们通过这种模式获得的宝贵的设计可扩展性是什么？我试图从互联网上的其他资源中找到信息，但在“大摇大摆优先”API开发方法的背景下找不到好的答案。任何关于这方面的见解都会非常有用

Answer 1

首先需要澄清的是：正如在评论中已经提到的，你没有被迫使用授权。相反，Spring生成器的默认行为是不使用委托模式，因为您可以轻松地在docs中进行检查。在这种情况下，它将只生成PersonApi接口和PersonapicController

说到你的问题，为什么要使用授权

这允许您编写一个实现PersonApiDelegate的类，该类可以轻松地注入到生成的代码中，而无需手动触摸生成的源代码，并确保实现在代码生成过程中不会受到未来可能发生的更改的影响

让我们想想没有授权会发生什么

一种简单的方法是生成源代码，然后直接在生成的PersonController中编写实现。当然，下一次需要运行发电机时，情况会变得一团糟。所有的实现都将丢失

一个稍好一些但并不完美的方案是编写一个扩展PersonController的类。这将确保实现在生成期间不会被覆盖，但不会保护它不受生成引擎未来更改的影响：至少实现类需要实现PersonControl构造函数。现在，生成的控制器的构造函数具有以下签名PersonApiController(ObjectMapper objectMapper, HttpServletRequest request)，但是生成器的开发人员将来可能需要更改它。因此，实施也需要改变

第三种方法是完全忘记生成的PersonapicController，只编写一个实现PersonApi接口的类。这很好，但每次生成代码时，您都需要删除PersonapicController，否则Spring router会抱怨。还是体力活

但是有了委托，实现代码是完全安全的。无需手动删除内容，无需在将来发生变化时进行调整。此外，实现PersonApiDelegate的类可以被视为一个独立的服务，因此您可以根据需要向其中注入/autowire