Spring MVC стал очень популярной платформой для создания веб-приложений предприятия. Любое сложное веб-приложение имеет определенные потоки, которые должны быть кодированы, включая некоторые условные потоки (т.е. выставочный заказ, обработанный, если бы данные кредитной карты были корректны, или ошибки проверки, если что-то не вводилось правильно).
Когда имеет смысл использовать Spring WebFlow сверху Spring MVC? Каков должен быть процесс принятия решений относительно использования Spring WebFlow?
Одна проблема, которую веб-поток решает эффективно, заключается в том, что он четко отделяет (или, по крайней мере, делает очень трудным смешивание) бизнес-логику от вашей управляющей логики.
Согласитесь с @John на варианты использования, но я хотел бы отметить, что как только вы начнете интенсивно использовать webflow, вы обнаружите, что пишете много файлов xml (поскольку в webflow вы указываете все потоки в файлах xml). Лично для меня это почти что нарушает условия сделки.
Если у вас есть веб-приложение, в котором есть какой-то процесс. Например, если у вас есть какой-то процесс регистрации, одна кнопка может переходить на одну страницу, а другая - на другую. Spring Webflow очень хорошо справляется с переходом к разным наборам процессов.
Обычно, если какая-то часть вашего приложения связана и страницы зависят друг от друга в ходе выполнения, SWF-файл хорошо использовать.
Что мне лично больше всего нравится в webflow, так это 2 вещи:
Что мне не нравится, так это несогласованность и плохая обратная совместимость новых версий. Например, последняя версия webflow 2.1 не совместима с JSF 1.x jira. Также существует множество проблем с интеграцией с Spring Security. Например, в Spring Security 3.x они просто изменили некоторые имена пакетов. В целом, как отметил Саси, webflow почти заставит вас разделить логику в разных webflow - и это хорошо, я думаю.