当我生成代码时Spring从我的 swagger yaml 中，通常控制器层是使用生成的delegate模式，以便为单个模型生成三个文件。例如，如果我定义了一个名为Person在我的 swagger/open API yaml 文件中，生成三个文件：
- PersonApi（包含所有人员操作/方法签名的接口）
- PersonApiDelegate（提供所有 PersonApi 方法的默认实现的接口。意味着要被重写）
- PersonApiController（其中引用了 PersonApiDelegate，以便任何实现都可以覆盖并提供自定义实现）
我的问题是，对于熟悉构建基于 swagger/openapi 生成代码的 api 的人来说，拥有这种模式的意义是什么，而不是仅仅使用 PersonController 类公开服务端点，而不是通过 PersonApi 接口，然后PersonApiDelegate 并最终通过 PersonApiController 公开服务？
我们通过这种模式获得的有价值的设计可扩展性是什么？我试图从互联网上的其他资源中查找信息，但在 swagger-first API 开发方法的背景下找不到好的答案。对此的任何见解都会非常有帮助。
首先澄清一下：正如评论中已经提到的，您并不是被迫使用委托。相反，Spring 生成器的默认行为是不使用委托模式，因为您可以轻松地检查docs https://openapi-generator.tech/docs/generators/spring/。在这种情况下，它将仅生成 PersonApi 接口和 PersonApiController。
回答你的问题，为什么要使用委托？
这允许您编写一个实现 PersonApiDelegate 的类，该类可以轻松地注入到生成的代码中，而无需手动触摸生成的源，并确保实现免受代码生成中未来可能发生的更改的影响。
让我们想想如果没有授权会发生什么。
一种简单的方法是生成源代码，然后直接在生成的 PersonController 中编写实现。当然，下次需要运行发电机时，那就麻烦大了。所有的实施都会丢失......
一个稍微好一点但并不完美的方案是编写一个扩展 PersonController 的类。这将保证实现在生成过程中不被覆盖，但不会保护它免受生成引擎未来更改的影响：作为最低限度，实现类需要实现 PersonController 构造函数。现在生成的控制器的构造函数具有以下签名PersonApiController(ObjectMapper objectMapper, HttpServletRequest request)，但生成器的开发人员将来可能需要更改它。因此，实施也需要改变。
第三种方法是完全忘记生成的 PersonApiController，而只编写一个实现 PersonApi 接口的类。那很好，但是每次生成代码时，您都需要删除 PersonApiController，否则 Spring 路由器会抱怨。还是手工作业...
但有了委托，实现代码就完全安全了。无需手动删除内容，也无需适应未来的变化。此外，实现 PersonApiDelegate 的类可以被视为一个独立的服务，因此您可以根据需要将其注入/自动装配。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
