Spring 5 WebFlux中@Controller和RouterFunction的

Question

现在Spring5中有两种公开HTTPendpoint的方法。

null

@RestController
@RequestMapping("persons")
public class PersonController { 

    @Autowired
    private PersonRepo repo;

    @GetMapping("/{id}")
    public Mono<Person> personById(@PathVariable String id){
        retrun repo.findById(id);
    }
}

@Bean
public RouterFunction<ServerResponse> personRoute(PersonRepo repo) {
    return route(GET("/persons/{id}"), req -> Mono.justOrEmpty(req.pathVariable("id"))                                             
                                                 .flatMap(repo::getById)
                                                 .flatMap(p -> ok().syncBody(p))
                                                 .switchIfEmpty(notFound().build()));
}

使用任何人的方法是否有性能差异？从头开始编写应用程序时，我应该使用哪一个。

Answer 1

对于@controller或@restcontroller注释，我们同意基于注释的模型，在该模型中，我们将注释用于映射（而且不仅仅用于映射），并因此产生副作用（这在函数世界中是不允许的）以使API工作。这种副作用可能是@valid注释，它为请求主体提供内置bean验证，或者@requestmapping带有整个控制器的根路径。

另一方面，通过路由器函数，我们去掉了包含API实现方面任何副作用的注释，并将其直接委托给函数链:router->handler。这两个非常适合构建基本的反应块：一个事件序列和两个主角，一个发布者和一个订阅者。

当我们讨论@controller时，我想说我们通常会从同步Java世界的角度考虑:servlets、ServletContext、ServletContext、ServletContinitializer、DispatcherServlet等。即使我们会从控制器返回mono，以使应用程序具有反应性，我们仍然会使用Servlet3.0规范，该规范支持随后，我们将使用相应的设计模式和方法来构建web应用程序。

另一方面，RouterFunction受到源自异步Java World-Netty及其信道模型的真正反应性方法的启发。

随后出现了一组新的用于反应环境的类及其API:ServerRequest、ServerResponse、WebFilter等。就我而言，它们是Spring团队根据前几年维护框架和理解新的web系统需求而设计的。这些要求的名称是反应宣言。

最近，我的团队面临着无法将Swagger与RouterFucntionendpoint集成的问题。它可能会支持@controlers，但Spring团队引入了他们的解决方案--Spring REST文档，该文档可以轻松地连接到反应式WebTestClient。我在这里使用“connected”这个词是因为它背后包含了真正的反应性含义：您可以轻松地在测试中构建API文档，而不必大摇大摆地使用过载的配置和副作用注释，而不必接触您的工作代码。

更新2020：尽管现在Spring Webflux已经可以使用OpenAPI规范与Swagger集成，但它仍然缺乏配置的简单性和透明度，在我看来，这是作为过时的MVC方法的一部分的结果。

由于没有性能影响，它可能会听到类似于“它绝对基于个人偏好使用什么”的内容。我同意，这确实是个人偏好，在两种选择中：前进或后退，当你让自己在同一个领域呆上十年。我认为Spring团队对@controller的反应性支持是为了使旧项目能够以某种方式与时间需求保持一致，并至少有机会进行迁移。如果您要从头创建web应用程序，那么不要犹豫，使用引入的Reactor栈。