Swagger 生成代码中委托设计模式的重要性？

如何解决Swagger 生成代码中委托设计模式的重要性？

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

1. PersonApi（包含所有人员操作/方法签名的接口）
2. PersonApiDelegate（提供所有 PersonApi 方法的默认实现的接口。打算被覆盖）
3. PersonApiController（它引用了 PersonApiDelegate，以便任何实现都可以覆盖并提供自定义实现）

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

我们通过这种模式获得的有价值的设计可扩展性是什么？我试图从互联网上的其他资源中查找信息，但在 swagger first API development approach 的上下文中找不到好的答案。对此的任何见解都会非常有帮助。

解决方法

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

回到您的问题，为什么要使用委托？

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

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

一种简单的方法是生成源代码，然后直接在生成的 PersonController 中编写实现。当然下次有需要运行生成器的时候，就麻烦大了。所有的实现都将丢失...

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

第三种方法是完全忘记生成的 PersonApiController，只编写一个实现 PersonApi 接口的类。那很好，但是每次生成代码时，您都需要删除 PersonApiController，否则 Spring 路由器会抱怨。还是手工...

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