2

Web 開発では、状態を最小化 (または排除) することを目的として、REST スタイルのアーキテクチャに多くの焦点が当てられています。私が見た Web フレームワークはすべて、このスタイルを強調しています (Django、Rails、flask など)。

これが一般的に Web に適していることには同意しますが、不十分な場合も多くあります。特に、ユーザーにプロセスをたどってもらいたい場合、つまり、いくつかのステップを提供したい場合、これらのステップを特定の順序で完了する必要がある場合を考えています (オプションのステップ、逸脱したパスなどを使用する可能性があります)。

これの良い例はショッピング カートかもしれません。最初に選択を行い、次に住所を入力し、配送タイプを選択し、支払いの詳細を入力して終了します。ユーザーがこれらの手順を省略したくない場合は、プロセスがより複雑になる可能性があります。理想的には、このロジックを実装の残りの部分から分離するために、このプロセスを別の場所で定義したいと考えています。

今私の質問：

  1. 有限状態マシンはここに行く方法ですか? これらのプロセスが複雑になり、多くの変更が必要になった場合でも、それらはうまく機能しますか?

  2. Web フレームワークによって、または Web フレームワークに対してどのようなオプションが提供されていますか (特に最適なソリューションに関心があるわけではありません)。

  3. そのようなプロセスが発生する興味深い/良い例は何ですか? ショッピング カートはわかりやすい例ですが、他にもたくさんあると思います。

4

1 に答える 1

2

  1. はい、そうです。ステート マシン (ワークフロー) を使用することは、あなたが説明した問題に対する適切な解決策です。適切に設計されていれば、コードをよりクリーンにすることができ、コードから混乱を取り除くことができます。各状態のロジックと遷移ロジックは State クラス オブジェクト内にカプセル化されるため、コードはよりクリーンで保守しやすくなります。実装は異なる場合があり (たとえば、遷移ロジックを保持する場所 - 状態内または別の遷移マネージャーを作成する)、個別の数学での状態マシンの正規の記述と一致しないため、より適切に機能するものを試してください。

  2. Ruby の場合、ワークフローを確認できます: https://github.com/geekq/workflowまたは stonepath: https://github.com/bokmann/stonepath。ステート マシン パターンは、javascript フレームワーク (SpoutCore) にもあります。独自の小さなステート マシン エンジンを実装することは難しくありません。

  3. 興味深い例？それらの多くは。注文処理、銀行業務、ゲーム。生理学的テスト、ゲーム、ビデオを含む行動修正モジュールを作成するときに、ステート マシンを使用しました。状態から状態への遷移は、テストが正しく回答されたかどうか、ゲームが正常にプレイされたかどうかなどに依存していました。

PS。ステート マシンとワークフローという用語を同義語として使用しましたが、それらは同じではありません。ここで議論されました: http://jmettraux.wordpress.com/2009/07/03/state-machine-workflow-engine/ . また、いくつかの Ruby コードとリンクもそこにあります。

于 2012-07-04T11:29:02.957 に答える