Przypadkiem użycia dla funkcji Web Flow jest rozwiązanie problemu związanego z logiką kontrolera, która obejmuje nawigację wielostronicową (przepływ strony lub kreator). Jeśli nie musisz mieć formularza podzielonego na wiele stron (lub potrzebujesz kilku małych formularzy do udziału w pojedynczej transakcji), prawdopodobnie nie potrzebujesz przepływu strony.
Jednak większość aplikacji tego wymaga. Coś więcej niż prosty CRUD oznacza korzyść.
Przepływy stron zapewniają naturalny bufor danych i mogą rozwiązywać problemy związane z korzystaniem z przycisków nawigacji wstecz i wieloma ramkami/kartami.
Jeśli myślisz o tym, jak przechowywać dane, które muszą żyć dłużej niż pojedyncze żądanie (często błędnym widokiem jest przechowywanie w HttpSession), to na pewno otrzymasz coś z Web Flow. Jeśli nie robisz czegoś takiego i przetwarzasz wszystko w zakresie wymagań, wtedy nie potrzebujesz Web Flow.
Aktualizacja: Web Przepływ może wyeliminować potrzebę wyspecjalizowanych klas kontrolera, aby wykonać następujące ścieżki od strony przejścia/aktualizacji formularzy wzdłuż ustalonej procedury. Jeśli nie musisz tego robić, możesz zaoszczędzić sobie wiele konfiguracji/złożoności, używając tylko MVC.
Ok, ale czy wszystko powinno być częścią przepływu? Powiedzmy, że mam ekran, który wyświetla tylko niektóre rekordy. Użytkownik może kliknąć rekord i zostanie przeniesiony na ekran, na którym może go zaktualizować ... może każdy rekord w widoku ma po prostu link do widoku aktualizacji i przekazuje identyfikator rekordu. Mógłbym napisać kontroler, żeby ustawić ten początkowy widok, albo mógłbym "przepłynąć" z jednym stanem. Nie rozumiem czegoś tutaj ... – Boden
W moim rozumieniu, powinieneś przejść wszystko lub nic z Web Flow. W opisywanym scenariuszu nie potrzebujesz żadnych wyspecjalizowanych kontrolerów. Ale aby odpowiedzieć na twoje pytanie tak, jak było pierwotnie sformułowane, tak, to jest celem Web Flow - aby wyeliminować potrzebę specjalizacji kontrolerów do obsługi interakcji typu workflow. – cwash