WFとは何ですか？
Windows Workflow Foundation（WF）は、 ワークフローを作成および実行するために設計されたマイクロソフトの新しいテクノロジーではなくなりました。 ただし、現時点ではあまり積極的に使用されておらず、多くの開発者はまったく聞いていません。 そして、彼女との私の知り合いは比較的最近になりました。 特定のカテゴリのタスクの実装でのWFの使用は正当化される以上のものです。 この点で、テクノロジー自体とその範囲について話し、特定のプロジェクトの実装におけるその使用例を検討したいと思います。
WFの重要な概念はアクティビティです。これは、WFランタイムで作業ユニットを実行するクラスです。 ワークフローとアクティビティという用語は、WFの文脈では同義です。 各アクティビティはアクションを実行します-文字通りプログラムコード（C＃など）。 アクティビティには、入力および出力パラメーター、変数があります。 アクティビティは、複数の子アクティビティの構成である場合があります。この場合、プロセスでは、親アクティビティは、内部ロジックに従ってランタイムでの子の起動を制御します。 たとえば、コアアクティビティライブラリ（.NET Frameworkに含まれる）のParallel Activityは、子を並行して起動します。 ワークフローIfは、名前から推測することは難しくないため、指定された条件を確認した結果に応じて2つの子要素のいずれかを起動します。
したがって、最終的に、ワークフローの作成は、通常、ベースライブラリのアクティビティと独自のデザインのアクティビティに基づいて、デザイナーでブロック図を作成することになります。 デザイナーで構築されたワークフローは、XAML（XML拡張）でエンコードされます。 デザイナーの外観を図に示します。
「良い、でも私にとっては何ですか？ -あなたが尋ねます。 「ブロックと矢印を掘るよりも、1キログラムのコードを書いたほうがいいです。」
実際、これは開始する価値がありませんでした。 私たち開発者はコードの読み書きに慣れていますが、私たちはそれをうまくやり、それを愛しています。 コードはよりコンパクトです。 コードにはコメントを残すことができます。 コードの変更は、バージョン管理システムで簡単に追跡できます。 別の100,500の引数を思いつくことができると思います。 しかし、WFテクノロジには次の注目すべき機能があることがわかりました。
まず、WFスキームとして表現されたアルゴリズムは、その状態を自動的に保存および復元できます。 これにより、作業から解放されるだけでなく、アプリケーションをスケーリングするための大きな機会が開かれます。 次の図に示す方が良いでしょう。
時間Aで、最初のコンピューターで、ワークフローは続行するために入力が必要になるポイントに到達します。 次に、状態が保存されます（すべての変数の値、指定されたポイントの引数）。 次に、一定の時間の後、必要な入力データが到着し、時間Bで状態が復元され、アルゴリズムは別のコンピューター上の保存されたポイントから機能し続けます。 C＃コードがこのプロパティを所有しているとすばらしいでしょう。
現在では、ロジックをコードの独立したセクションに分割するのが慣例となっています。 特に、スケーラビリティを確保するため。 たとえば、 LogOnとGetDataの 2つのメソッドを考えます。 これまでのところ、 LogOnメソッドが最初に呼び出され、その後GetDataが呼び出されることは明らかです。 しかし、そのようなメソッドが多数ある場合、ロジック（アプリケーション全体に「拡散」することができます）とその実行順序を理解するのは困難です。 WFを使用するとこの問題が解消されます。ワークフロー全体のスレッドを接続する個別のタスクがわかりやすいフローチャートで表示されるため、経験のない開発者でも起動のルールをすばやく把握できます。
WFの次の完全に適用される機能は無視できませんが、このような柔軟性が必要な場合にソフトウェアロジックをシステム構成領域に移動する機能です 。 つまり、標準の.NET Framework配信のコンポーネントから、ソフトウェア製品の一部としてデザイナーを組み立てることができます。 システムのセットアップ段階で、ワークフローが変更され、そのプロパティが管理されます（たとえば、起動条件）。 さらに、必要なポイントでの操作中に実行されるのは「ハードコード」ではなく、以前に作成されたアクティビティです。 したがって、WFとDynamic LINQの組み合わせは、システムにカスタマイズ性などの品質を与える強力なツールです。 しかし、もちろん、このようなシステムを構成するために、.NETプログラミングスキルはまったく必要ないとは言えません。
フレームワークの使用が真に正当化されることが重要です。 顧客が独自に実装したアプリケーションで、現在のプロジェクトの技術の不合理なアプリケーションのアンチパターンの古典的な例を見る。 実際、WFスキームをC＃のコードの代替として使用しますが、最終的には、変更を行ったすべての開発者がテクノロジーを知らないために大幅に劣化しました。 しかし、結果として生じる「フランケンシュタイン」はゆっくりですが、それでもその義務を果たしていると言わなければなりません1 。
上記の利点を使用せずにWFを使用することはできません。 この場合、メリットはあるものの、恐らくは理解していなくても、テクノロジーの欠点を活用します。 これは新しい技術を学ぶときによく起こりますが、多くの人が考えるように、履歴書の追加の行は、不適切なコードをサポートするための雇用主の労力です。 しかし、公平に言えば、この場合、習得した知識とスキルから得られる利益は、私には思えないほど大きいとは言いません。
私たちのチームがタイプのユーザーストアを実装するタスクを受け取ったとき：「ディレクターとして、従業員の休暇の申請をシステムの直属の上司と調整したいので、人事部に行き、注文を作成し、私の署名の後、会計部門はエラーや遅延をなくし、コストを削減するための休暇手当」-WFテクノロジは、その実装に最適であることがわかりました。 この場合、上記のすべての機能を使用できます。
次のパートでは、この例でのWFの適用の実際的な例を検討します。
______________
1このプロジェクトは古いWF 3.0を使用しています。 Microsoft .NET Framework 4.0は、新しい名前空間でWFを完全に書き換えたことが知られています。 パフォーマンスの最適化は改善点の1つです。
