手作業(コード)で簡単に実装できるものもありますが、WFを使用すると簡単なものもあります。WFを使用して(ほとんど)あらゆる種類のアルゴリズムを作成できるようです。したがって、(理論的には)すべてのロジックをWFで実行できますが、すべてのプロジェクトで実行することはおそらくお勧めできません。
どのような状況でWFを使用するのが良いでしょうか。それが困難になるのはいつですか。手作業によるWFとコーディングのメリットとデメリット/コストとは何ですか?
手作業(コード)で簡単に実装できるものもありますが、WFを使用すると簡単なものもあります。WFを使用して(ほとんど)あらゆる種類のアルゴリズムを作成できるようです。したがって、(理論的には)すべてのロジックをWFで実行できますが、すべてのプロジェクトで実行することはおそらくお勧めできません。
どのような状況でWFを使用するのが良いでしょうか。それが困難になるのはいつですか。手作業によるWFとコーディングのメリットとデメリット/コストとは何ですか?
回答:
次のいずれかに該当する場合にのみ、WFが必要になることがあります。
詳細については、Paul Andrewの投稿「Windows Workflow Foundationの用途」を参照してください。
WFをあらゆる種類のビジュアルプログラミングと混同または関連付けないでください。これは誤りであり、非常に悪いアーキテクチャ/設計の決定につながる可能性があります。
決して。あなたはおそらくそれを後悔するでしょう:
私がWFを使用することを思いつくことができるのは、エンドユーザーのためにデザイナーをホストしたいと思ったときだけであり、おそらくそれさえもしません。
私を信じて、あなたがそれをするために必要なことを正確に行うためにあなたが書くコードほど、単純で強力で柔軟なものは決してありません。WFに近づかないでください。
もちろん、これは私の意見に過ぎませんが、私はそれがいまいましいものだと思います。:)
一般に、永続性と追跡機能(私の意見では主な機能です)が必要ない場合は、Workflow Foundationを使用しないでください。
私の経験から集めたWorkflow Foundationの長所と短所は次のとおりです。
メリット
短所
ワークフローの基盤を使用することで私が見つけた主な理由は、追跡と永続性の観点から、どれだけすぐに使えるかです。永続化サービスを稼働させるのは非常に簡単で、複数のインスタンスとホスト間で信頼性と負荷分散を実現します。
一方、フォームアプリと同様に、ワークフローデザイナーがプッシュするコードパターンは不適切です。ただし、ワークフローにコードを記述せず、すべての作業を他のクラスに委任することで問題を回避できます。他のクラスは、ワークフローよりも適切に整理およびユニットテストできます。次に、スパゲッティコードの残骸なしでデザイナーのクールな視覚的側面を取得します。
私が現在Windows Workflow Foundation(WF)のセットアップに取り組んでいる会社と、それを使用することを選択した理由は、ルールが頻繁に変更されるため、さまざまなdllなどの再コンパイルを強制され、ソリューションルールをDBに配置してそこから呼び出すことでした。このようにして、ルールを変更し、DLLを再コンパイルして再配布する必要がなくなります。
Windowsワークフローは、従兄弟のBizTalkと同様に、非コーディングITマネージャー、BAなどを誘惑しますが、実際の単体テストでは、デバッグとコードカバレッジは多くの落とし穴のうちの3つにすぎません。あなたはそれらのいくつかを克服することができますが、あなたはそれを達成するために多額の投資をしなければなりませんが、プレーンコードではあなたはそれを得るだけです。本当に長期的な要件がある場合は、おそらくもっと洗練されたものが必要です。dllを再コンパイルせずに新しいxamlファイルを本番環境にドロップできるという議論を聞いたことがありますが、正直なところ、ワークフローが消費する時間は、コンパイルされたデプロイが問題にならない程度まで継続的インテグレーションを改善するために使用できます。
ワークフローを使用する必要があるすべての環境で使用しますが、K2またはSharePoint 2007と組み合わせて使用する場合は、プラットフォームのパワーが本当に役立ちます。BIスペシャリストがビジネスアプリケーションを開発する場合、プラットフォームの使用が推奨されます。これは通常、ビジネスプロセスの合理化と改善にのみ関連します。
記録では、WFはK2の開発チームと共同で開発され、新しいK2 BlackpearlはWFの上に構築されているため、MOSS 2007およびWSS 3.0のワークフローエンジンも同様です。
私は何ヶ月もWindowsワークフローを使用してカスタムアクティビティを開発し、非開発者がワークフローの構築に使用できる再ホストされたデザイナーを開発しています。WFは非常に強力ですが、開発者が作成したカスタムアクティビティと同じくらい優れています。つまり、開発者はテストやデバッグのために、開発者以外が作成したワークフローを確認する必要がありますが、その時点から、ドラフトワークフローを作成できます。これは素晴らしいことです。
さらに、長時間実行しているプロセスがある場合、WFはプロセスを動的に更新する必要があるときに使用するのに適した技術スタックです。再インストール/ダウンロードしたり、何かをしたりする必要なく、新しいXAMLファイルをディレクトリに追加するだけで、アーキテクチャは古いバージョンを破棄して新しいバージョンを使用するようにバージョン管理を設定します。