154

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

どのような状況で WF を使用することをお勧めしますか? また、WF を使用すると、必要以上に困難になるのはどのような場合ですか? 手動でコーディングする場合と比較して、WF の長所と短所/コストは何ですか?

4

11 に答える 11

125

次のいずれかに該当する場合にのみ、WF が必要になることがあります。

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

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

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

于 2008-09-21T16:05:10.367 に答える
86

一度もない。あなたはおそらくそれを後悔するでしょう：

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

私が WF の使用を思いついたのは、エンド ユーザーのためにデザイナーをホストしたい場合だけでした。

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

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

于 2011-12-21T18:11:09.693 に答える
46

WF によって生成されたコードは厄介です。WF がもたらす価値は、システムの視覚的表現にありますが、単純なハンド コーディング プロジェクトを好まなかったと思われるものはまだ見たことがありません (私が関わった WF を使用して、現在 6 ～ 7 個のプロジェクトが進行中です)。 .

于 2008-09-19T18:02:17.497 に答える
42

一般に、永続化機能と追跡機能 (私の意見ではこれらが主な機能です) が必要ない場合は、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 サービスがすべてのインターフェイスを実装していることを保証できません。インターフェイスを定義する必要さえありません。（私の知る限りでは...）
于 2013-07-29T11:14:38.313 に答える
27

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

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

于 2008-09-19T18:10:12.660 に答える
11

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

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

于 2008-09-19T18:03:42.347 に答える
6

Windows ワークフローは、いとこの BizTalk と同様に、非コーディングの IT マネージャーや BA などを誘惑しますが、実際には、単体テスト、デバッグ、およびコード カバレッジは多くの落とし穴の 3 つに過ぎません。それらのいくつかを克服することはできますが、それを達成するために多額の投資を行う必要がありますが、単純なコードではそれを得ることができます. 本当に長期にわたる要件がある場合は、おそらくもっと洗練されたものが必要です。dll を再コンパイルせずに新しい xaml ファイルを本番環境にドロップできるという議論を聞いたことがありますが、正直なところ、ワークフローが消費する時間を、コンパイル済みのデプロイが問題にならない点まで継続的インテグレーションを改善するために使用する方がよいでしょう。

于 2014-08-15T05:58:38.610 に答える
3

ワークフローで作業する必要があるあらゆる環境で使用しますが、K2 や SharePoint 2007 と組み合わせて使用​​する場合、プラットフォームのパワーは本当に役に立ちます。BI スペシャリストと共にビジネス アプリケーションを開発する場合は、プラットフォームの使用が推奨されます。これは通常、ビジネス プロセスの合理化と改善にのみ関連します。

ちなみに、WF は K2 の開発チームと協力して開発されました。新しい K2 Blackpearl は WF の上に構築されており、MOSS 2007 と WSS 3.0 のワークフロー エンジンも同様です。

于 2008-09-21T18:13:11.947 に答える