当我从swagger yaml中生成Spring的代码时，通常控制器层是使用delegate模式生成的，因此对于单个模型，会生成三个文件。例如，如果我在swagger/open API yaml文件中定义了一个名为Person的模型，则会生成以下三个文件：
- PersonApi（包含所有人员操作/方法签名的接口）
- PersonApiDelegate（提供所有PersonApi方法的默认实现的接口。意味着被覆盖）
- PersonApiController（它有一个对PersonApiDelegate的引用，这样任何实现都可以覆盖并提供自定义实现）
我的问题是，对于任何熟悉构建swagger/openapi生成的基于代码的api的人来说，拥有这样一个模式的意义是什么，而不是仅仅使用PersonController类公开您的服务端点，而不是通过PersonApi接口，然后到PersonApiDelegate，最后通过PersonApiController公开服务？
我们通过这个模式获得的有价值的设计可扩展性是什么？我试图从互联网上的其他资源中找到信息，但无法在swagger first API开发方法的上下文中找到一个好的答案。任何关于这方面的见解都将是非常有帮助的。
1条答案
按热度按时间am46iovg1#
首先澄清一下：正如在注解中已经提到的，您不必使用委托。相反，Spring生成器的默认行为是不使用委托模式，因为您可以轻松检入docs。在这种情况下，它将只生成PersonApi接口和PersonApiController。
回到你的问题，为什么要使用授权？
这允许您编写一个实现PersonApiDelegate的类，它可以很容易地注入到生成的代码中，而不需要手动接触生成的源代码，并保持实现安全，免受代码生成中可能的未来更改。
让我们想想没有授权会发生什么。
一种简单的方法是生成源代码，然后直接在生成的PersonController中编写实现。当然，下一次有需要运行发电机的时候，那就是一个大烂摊子了。所有的实现都将丢失。..
一个稍微好一点但并不完美的方案是编写一个扩展PersonController的类。这将使实现在生成过程中不会被覆盖，但不会保护它免受生成引擎的未来更改：作为最低限度，实现类需要实现PersonController构造函数。现在生成的控制器的构造函数具有以下签名
PersonApiController(ObjectMapper objectMapper, HttpServletRequest request)，但生成器的开发人员可能需要在将来更改它。因此，实施方式也需要改变。第三种方法是完全忘记生成的PersonApiController，只编写一个实现PersonApi接口的类。这很好，但是每次生成代码时，您都需要删除PersonApiController，否则Spring路由器会抱怨。仍然是手工工作。..
但是通过委托，实现代码是完全安全的。不需要手动删除内容，不需要适应未来的变化。实现PersonApiDelegate的类也可以被视为一个独立的服务，因此您可以根据需要将/ autowire注入其中。