比較的シンプルなアプリケーションでは、Webflowを使用してフォームコントローラを作成する必要性を減らすことができますか？まあ、確かに可能ですが、私が尋ねることは次のようなものです：私が書いたコードの量を減らすことが私の目的なら、コントローラ/ビューロジックすべてに対してWebflowを使ってアプリケーション全体を書くことができますか？ ？Spring Webflowはコントローラクラスの必要性を排除できますか？
私は（貧困層）のWebflowのドキュメントを通じて自分の道を苦労だし、それはそれの価値がある場合は疑問に思って、または私は通常のMVCに固執する必要がある場合。
ウェブフローのユースケースは、複数ページのナビゲーション（ページフロー、またはウィザード）をまたがる制御ロジックに伴う問題を解決することです。フォームを複数のページに分割する必要がない場合や、単一のトランザクションに参加するために複数の小さなフォームが必要な場合は、おそらくページフローは必要ありません。
しかし、ほとんどのアプリケーションでこれが必要です。シンプルなCRUD以上のものはどれも有益です。
ページフローは、データのための自然なキャッシュを提供し、ボタンのナビゲーションおよび複数のフレーム/タブをバック使用時にそれ以外の問題点を解決することができます。
1つのリクエストよりも長く生きる必要のあるデータを保存する方法について考えているなら、間違った見方はHttpSessionに保存することですが、Web Flowから何かを得ることは間違いありません。あなたがそのようなことをしておらず、リクエストスコープですべてを処理しているなら、Web Flowは必要ありません。
更新： のWeb Flowは事前に定義されたワークフローに沿ってページ遷移/フォームのアップデートのパス以下を達成するために専門のコントローラクラスの必要性を排除することができます。これを行う必要がない場合は、MVCを使用するだけで多くの設定/複雑さを省くことができます。
SpringMVCとSpring WebFlowは、必要に応じて一緒に使用することができます。
あなたはユースケースを持っている場合は、単純なCRUDで、あなたは簡単にこの使用SpringMVCを実装することができ、その後それはおそらく正しい選択だと思います。
注：また、あまりにも、より良いか、最悪でもないというのWebflowでこれを達成することができました。あなたは、複雑なウィザードのロジックと状態管理の要件を持っている場合は
は、Webflowのは素晴らしいですプラスあなたは、トランザクションや永続化のサポート（バージョン2）のような無料のために他の多くの機能を取得します。
すべてがフローの一部である必要がありますか？私はいくつかのレコードを表示するだけの画面があるとしましょう。ユーザーはレコードをクリックして、そのレコードを更新できる画面に移動します。おそらく、ビュー内の各レコードは単に更新ビューへのリンクを持ち、レコードIDを渡します。最初のビューを設定するためのコントローラーを書くことができます。または、1つの状態で「フロー」を持つことができます。私はここで何かを理解していません... – Boden
私の理解では、あなたはWeb Flowですべてか何かに行かなければなりません。ここで説明するシナリオでは、特別なコントローラーは必要ありません。しかし、当初の言い回しであったように質問に答えるためには、ワークフローのタイプのやりとりを処理するためにコントローラーを特殊化する必要性を排除するために、これがWeb Flowの目標です。 – cwash