Windows Workflow Foundation を使用するのはどのような場合ですか?[閉まっている]

StackOverflow https://stackoverflow.com/questions/104099

質問

手動 (コード) だけで実装するほうが簡単なものもありますが、WF を使用するほうが簡単なものもあります。WF を使用すると、(ほぼ)あらゆる種類のアルゴリズムを作成できるようです。したがって、(理論的には) すべてのロジックを WF で実行できますが、すべてのプロジェクトに対してそれを実行するのはおそらく悪い考えです。

どのような状況で WF を使用するのが得策ですか?また、WF を使用すると事態が必要以上に困難になるのはどのような場合ですか?WF と WF の長所と短所、コストは何ですか?手動でコーディングしますか?

役に立ちましたか?

解決

WF が必要になるのは、次のいずれかに該当する場合のみです。

  1. 長時間実行されるプロセスがあります。
  2. 頻繁に変更されるプロセスがあります。
  3. プロセスの視覚的なモデルが必要です。

詳細については、Paul Andrew の投稿を参照してください。 Windows Workflow Foundation は何に使用するのですか?

WF をいかなる種類のビジュアル プログラミングとも混同したり関連付けたりしないでください。それは間違っており、非常に悪いアーキテクチャ/設計上の決定につながる可能性があります。

他のヒント

一度もない。おそらく後悔するでしょう:

  • 急な学習曲線
  • デバッグが難しい
  • 維持が難しい
  • 使用を正当化するのに十分なパワー、柔軟性、生産性の向上が得られない
  • 回復できないアプリケーションの状態が破損する可能性がある、または破損する可能性がある

WF の使用を思いつくのは、エンドユーザーのためにデザイナーをホストしたい場合だけであり、おそらくその場合でもありません。

信じてください。必要なことを正確に実行するために作成するコードほど単純で、強力で、柔軟なものはありません。WFから離れてください。

もちろん、これは私の意見にすぎませんが、非常に良い意見だと思います。:)

WF によって生成されたコードは厄介です。WF がもたらす価値は、システムの視覚的表現にあります。ただし、私はまだ何も見ていません (私が関与している WF で現在 6 ~ 7 つのプロジェクトが進行中) が、より単純な手動コードのプロジェクトを好まないと思われる箇所はありません。 。

一般に、永続化機能と追跡機能 (私の意見では、これが主要な機能です) が必要ない場合は、Workflow Foundation を使用しないでください。

私の経験から収集した Workflow Foundation の長所と短所は次のとおりです。

利点

  • 永続性:長時間実行されるプロセス (数日、数週間、数か月を考えてください) が多数ある場合、ワークフローはこれに最適です。アイドル状態のワークフロー インスタンスはデータベースに永続化されるため、メモリを消費しません。
  • 追跡:WF は、ワークフローで実行される各アクティビティを追跡するメカニズムを提供します。
  • *ビジュアルデザイナー:これを * としたのは、これは実際にはマーケティング目的でのみ役立つと思うからです。開発者として、私は視覚的に物事を組み立てるよりもコードを書くことを好みます。また、開発者以外がワークフローを作成すると、非常に混乱した状態に陥ることがよくあります。

短所

  • プログラミングモデル:プログラミング機能は非常に限られています。C# にあるすべての優れた機能について考えてから、それらのことは忘れてください。C# の単純な 1 行または 2 行のステートメントは、かなり大きなブロック アクティビティになります。これは、入力検証の場合に特に厄介です。そうは言っても、ワークフロー内の高レベルのロジックのみを保持し、それ以外はすべて C# に保持するように十分に注意しているのであれば、問題ないかもしれません。
  • パフォーマンス:ワークフローは大量のメモリを使用します。サーバー上に多数のワークフローをデプロイする場合は、大量のメモリがあることを確認してください。また、ワークフローは通常の C# コードよりもはるかに遅いことにも注意してください。
  • 急な学習曲線、デバッグが難しい:上記のように。物事をうまく機能させる方法を考えたり、何かを行うための最善の方法を見つけたりするのに多くの時間を費やすことになります。
  • ワークフローのバージョンの非互換性:永続性を備えたワークフローをデプロイし、ワークフローを更新する必要がある場合、古いワークフロー インスタンスには互換性がなくなりました。おそらく、これは .NET 4.5 で修正されると思われます。
  • VB 式を使用する必要があります (.NET 4.5 では C# 式が可能です)。
  • 柔軟性がない:Workflow Foundation が提供していない特別な機能が必要な場合は、多大な労力を覚悟してください。場合によっては、それが不可能な場合もあります。試してみるまで誰にも分かりません。ここには多くのリスクがあります。
  • インターフェイスのない WCF XAML サービス:通常、WCF サービスでは、インターフェイスに対して開発します。WCF XAML サービスでは、WCF XAML サービスがインターフェイス内のすべてを実装していることを保証できません。インターフェイスを定義する必要さえありません。(私の知る限りでは...)

私がワークフロー基盤を使用する主な理由は、追跡と永続性の点で、すぐに使用できるようになるということです。永続化サービスを立ち上げて実行するのは非常に簡単で、これにより複数のインスタンスとホスト間の信頼性と負荷分散が実現します。

一方、フォーム アプリと同様に、ワークフロー デザイナーが押し付けるコード パターンは不適切です。ただし、ワークフローにコードを記述せず、すべての作業を他のクラスに委任することで問題を回避できます。他のクラスは、ワークフローよりも適切に編成および単体テストを行うことができます。そうすれば、スパゲッティ コードのような複雑なコードを使わずに、デザイナーのクールなビジュアル面を得ることができます。

個人的にはWFには興味がありません。その有用性は、WPF や WCF などの他の新しい MS テクノロジほど明らかではありませんでした。

WF は将来ビジネス アプリケーションで頻繁に使用されるようになると思いますが、私のプロジェクトの仕事に適したツールとは思えないため、使用する予定はありません。

私が現在働いている会社は 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 のワークフロー エンジンも同様です。

視覚的なインターフェイス、追跡、永続性を維持するためにこれらすべてのコードを手動で記述したくない場合は、WF に投票するのが賢明な選択です。

私はここ数カ月間、Windows ワークフローを使用して、カスタム アクティビティと、開発者以外のユーザーがワークフローの構築に使用できる再ホストされたデザイナーを開発してきました。WF は非常に強力ですが、開発者によって構築されたカスタム アクティビティと同等の性能しかありません。結局のところ、開発者はテストやデバッグのために開発者以外が構築したワークフローを確認する必要がありますが、ワークフローの草案を作成できるという点では素晴らしいことです。

さらに、プロセスの実行時間が長い場合、プロセスを動的に更新する必要がある場合に WF を使用するのに適した技術スタックです。再インストール/ダウンロードなど何もせずに、新しい XAML ファイルをディレクトリに追加するだけで、アーキテクチャは次のようになります。バージョン管理を設定して古いバージョンを破棄し、新しいバージョンを使用します。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top