非常に単純なステート マシンの注文処理アプリケーションを実装しています。ひねりを加えた電子商取引アプリケーションです。アプリケーションのユーザーは、自分でワークフローを編集することはありません。
Microsoft は、asp.net と Windows Workflow を組み合わせることが可能であると主張しています。asp.net と Windows ワークフローの組み合わせをインストールして維持するのはどれくらい難しいですか? ワークフローの状態を sql-server に保持します。
独自のステート マシン コードを展開する方が簡単ですか、それとも Windows ワークフローはその作業に適したツールですか?
Asp.net と WF は問題なく連携しており、WF はメンテナンスのオーバーヘッドをあまり追加しません。
これが適切な設計であるかどうかは、ニーズに大きく依存します。イベント ドリブン アクションが多い場合は、WF を使用する価値があります。そうでない場合は、独自の追跡をロールするオーバーヘッドにより、システムの複雑さが軽減される可能性があります。
WF は比較的簡単に操作できるので、プロトタイプを作成して試してみることをお勧めします。
また、私の意見では、あなたの要件に基づいて、WF が適切なソリューションになるとは思えません。
それはあなたのニーズに依存します。ステートマシンはどのくらい複雑ですか? ステート マシンをどこに配置しますか (例: モデルとデータベース)? WWF はイベント ベースのステート マシンを提供します。これは、ステート マシンがモデルに組み込まれている場合に十分です。
個人的には、e コマース フレームワークやその他のワークフロー ベースの Web サイトを実装してきました。また、データベース ベースのステート マシンを実装することには、常に大きな喜びを感じてきました。いつも滞りなく働いていました。
一方、私の同僚の中には WWF を好む人もいます。
いずれにせよ、ASP.NET と完全に連携します。
ステート マシンが非常に単純な場合は、自分でロールする必要があります。すべてをより細かく制御できます。自分の条件で持続性に対処することができ、彼らがどのようにそれを行うかについて心配する必要はありません.
WFは確かにかっこいいですが、CRMやSharepointなどのフレームワークに結び付けやすいところに強みがあるのではないでしょうか。これらをアプリケーションで使用する場合は、WF の使用を検討することをお勧めします。
完全な開示: 私は絶対に WF の専門家ではありません。