Я изучаю Spring 5 webflux и реактивные потоки. И есть новые функции HandlerFunctions и RouterFunctions для реализации запросов и ответов Http.

И согласно документации:

Аналогом аннотации функции обработчика будет метод с @RequestMapping.

Поскольку @RequestMapping довольно легко обрабатывать, внедрять и понимать, тогда зачем нужен более сложный и трудный способ обработки запросов и ответов Http с помощью этой утилиты HandlerFunctions и RouterFunction?

Пожалуйста, предложите.

2
KayV 2 Янв 2018 в 10:24

2 ответа

Лучший ответ

Spring WebFlux предоставляет вам два разных стиля: аннотации и функциональный.

В зависимости от типа приложения, которое вы хотите создать, ограничения, с которыми вам придется иметь дело - одно или другое могут быть более актуальными. Вы даже можете смешать и то, и другое в одном приложении.

Модель на основе аннотаций очень успешна, но она также имеет несколько ограничений, в основном из-за самих аннотаций Java:

  • путь кода не всегда ясен, если вы не знакомы с внутренним устройством Spring Framework (знаете ли вы, где обнаруживаются сопоставления обработчиков? сопоставляются с входящими запросами?)
  • он использует отражение, которое требует затрат
  • может быть сложно отладить и расширить

Функциональный вариант пытается исправить эти проблемы и охватывать функциональный стиль (с API функций JDK8) и неизменность. В нем есть «больше библиотеки; меньше фреймворков», что означает, что вы лучше контролируете вещи. Вот пример: с RouterFunction вы можете связать RequestPredicates, и они будут выполняться по порядку, так что вы полностью контролируете, что в конечном итоге обрабатывает входящий запрос. В модели аннотаций будет выбран наиболее конкретный обработчик, просмотрев аннотации к методу и входящему запросу.

Если вас полностью устраивает модель аннотаций, нет причин переключаться. Но, опять же, вы можете смешивать и то, и другое, и, возможно, вам пригодится функциональная модель. На мой взгляд, попробовать это, даже если вы не планируете внедрять, не повредит - в худшем случае это немного расширит ваши перспективы как разработчика и покажет вам другой способ работы.

Чтобы узнать больше об этом, вы можете ознакомиться с докладом Арьена Поутсмы о функциональной веб-платформе в Spring WebFlux..

3
Brian Clozel 7 Июн 2018 в 09:56

Это не нужно и не нарушает работу webflux. Я бы использовал @RequestMapping, если у вас нет особых потребностей, требующих HandlerFunction.

Для RouterFunctions: если вы не хотите использовать синтаксический анализ JSON и хотите напрямую изменить ServerRequest (например, иметь необработанный InputStream), вам придется использовать RouterFunctions (AFAIK). Затем вы также вернете необработанный поток (Mono). У меня был случай, когда мне нужно было поиграть в прокси с небольшим дополнительным оборудованием, и поэтому мне нужно было избежать синтаксического анализа JSON, который обычно бывает с @RequestMapping

0
Frischling 6 Июн 2018 в 11:32