いつWindows Workflow Foundationを使用するのですか?[閉まっている]


154

手作業(コード)で簡単に実装できるものもありますが、WFを使用すると簡単なものもあります。WFを使用して(ほとんど)あらゆる種類のアルゴリズムを作成できるようです。したがって、(理論的には)すべてのロジックをWFで実行できますが、すべてのプロジェクトで実行することはおそらくお勧めできません。

どのような状況でWFを使用するのが良いでしょうか。それが困難になるのはいつですか。手作業によるWFとコーディングのメリットとデメリット/コストとは何ですか?


3
これらの回答の後に出てきた4.0リリース用に完全に書き直されたことは注目に値するようです。
sclarson、2015年

回答:


125

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

  1. あなたは長期にわたるプロセスを持っています。
  2. 頻繁に変化するプロセスがあります。
  3. プロセスの視覚モデルが必要です。

詳細については、Paul Andrewの投稿「Windows Workflow Foundationの用途」を参照してください

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


4
長時間プロセスの測定ユニットは何ですか?
ivorykoder 2013

5
@ivorykoder「プロセス」(実際にはワークフロー)。これをホストするサーバーの再起動後も存続できます。
ロブスター主義2013

#1を満足するだけの要件がある場合、WFを選択するにはそれだけでは不十分です。ただし、要件に#2や#3が含まれている場合は、WFを使用する場合の方がはるかに強力です。
Mick

12
私は抵抗できません:次のいずれかに該当する場合にのみWFが必要になる場合があります:false。
Ronnie Overby

84

決して。あなたはおそらくそれを後悔するでしょう:

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

私がWFを使用することを思いつくことができるのは、エンドユーザーのためにデザイナーをホストしたいと思ったときだけであり、おそらくそれさえもしません。

私を信じて、あなたがそれをするために必要なことを正確に行うためにあなたが書くコードほど、単純で強力で柔軟なものは決してありません。WFに近づかないでください。

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


27
-1私はこれについてあなたの意見を尊重しますが、理由の専門家による説明をはるかに一般化します。この種の答えがどのように誰に役立つか
わかりません

9
この回答は、WF4に腹を立てた日に書きました。私が直面した問題で私の答えを更新します。
ロニーオーバーバイ2012年

5
私たちは、WFをバックボーンとするコンサルタントから半分完成したプロジェクトを受け継ぎました。エラー、再起動できない破損したワークフロー、マイナーな変更のためにワークフローの完全な複製を必要とする古いバージョン管理システム、恐ろしい生成コード、および子供用手袋で処理しなければならないようなデリケートなコードが発生しやすかった。6か月の死の黄色い画面の後、WF全体を破棄し、代わりにxmlを使用しました。今までで最高の決断。
Kevin DeVoe 2013

10
「使用を正当化するのに十分なパワー、柔軟性、または生産性の向上を提供しない」という語句は、私には十分に語っています。有難うございます。
David Tansey 2013年

1
憎しみは彼らの憎しみを説明する必要があります。
ロニーオーバーバイ2014年

46

WFによって生成されたコードは厄介です。WFがもたらす価値は、システムの視覚的表現にありますが、私はまだ何も見ていません(私が関与しているWFを使用して現在作業中の6〜7個のプロジェクト)。 。


40

一般に、永続性と追跡機能(私の意見では主な機能です)が必要ない場合は、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サービスがすべてをインターフェイスに実装したことを確認できません。インターフェースを定義する必要すらありません。(私の知る限りでは...)

7
あなたの欠点のほとんどは単に本当ではありません、多分あなたはWFに十分に精通していません。WFは非常に柔軟です。任意のシナリオで再利用できるカスタムアクティビティ(コードアクティビティ)を記述できます。再利用可能なアクティビティを書くのはあなた次第です。アクティビティのツールセットと共にGUI(ワークフローデザイナホストを備えたWPFアプリ)をビジネスコンサルタントに提供できると想像してください。これで、ビジネスロジックをニーズに合わせて変更および再配置できるようになり、開発者を必要とせず、新しいアプリケーションをコンパイルする必要もありません。
Sven

3
次に、ビジネスコンサルタントがセルフホストデザイナーを使用する必要があるが、Intellisenseがないと想像してください。自分でロールするか、Visual Studioを使用する必要があります。また、ビジネスコンサルタントが、補償、キャンセル、例外処理などの概念の一部を理解することも難しいと思います。また、イベントがリモートで複雑なロジックは、巨大なワークフローを維持できなくなります(そうすると、そのようなワークフローを編集するには大量のRAMが必要になります)。しかし、丁寧に作成されたカスタムアクティビティにより、かなりの柔軟性が提供されます。
2015

27

ワークフローの基盤を使用することで私が見つけた主な理由は、追跡と永続性の観点から、どれだけすぐに使えるかです。永続化サービスを稼働させるのは非常に簡単で、複数のインスタンスとホスト間で信頼性と負荷分散を実現します。

一方、フォームアプリと同様に、ワークフローデザイナーがプッシュするコードパターンは不適切です。ただし、ワークフローにコードを記述せず、すべての作業を他のクラスに委任することで問題を回避できます。他のクラスは、ワークフローよりも適切に整理およびユニットテストできます。次に、スパゲッティコードの残骸なしでデザイナーのクールな視覚的側面を取得します。


11

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

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


7

私が現在Windows Workflow Foundation(WF)のセットアップに取り組んでいる会社と、それを使用することを選択した理由は、ルールが頻繁に変更されるため、さまざまなdllなどの再コンパイルを強制され、ソリューションルールをDBに配置してそこから呼び出すことでした。このようにして、ルールを変更し、DLLを再コンパイルして再配布する必要がなくなります。


21
あまりにもひどい通常のWebサービスとアプリケーションには.configファイルがなく、データベースを読み取ったり、XMLやルールを含むローカルファイルを読み取ったりすることができず、再コンパイルする必要があります。ああ待って...
Dour High Arch

6

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


3

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

記録では、WFはK2の開発チームと共同で開発され、新しいK2 BlackpearlはWFの上に構築されているため、MOSS 2007およびWSS 3.0のワークフローエンジンも同様です。


2

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


1

私は何ヶ月もWindowsワークフローを使用してカスタムアクティビティを開発し、非開発者がワークフローの構築に使用できる再ホストされたデザイナーを開発しています。WFは非常に強力ですが、開発者が作成したカスタムアクティビティと同じくらい優れています。つまり、開発者はテストやデバッグのために、開発者以外が作成したワークフローを確認する必要がありますが、その時点から、ドラフトワークフローを作成できます。これは素晴らしいことです。

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

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.