5

私は、IEnumerable メソッドを介して作業項目を公開するワークフローとして幅広い範囲のタスクを表現できるようにするシステムを設計中です。ここでの意図は、C# の「yield」メカニズムを使用して、ワークフロー実行システムが適切と判断したときに実行できる疑似手続き型コードを記述できるようにすることです。

たとえば、データベースでクエリを実行し、クエリが特定の結果を返した場合に電子メール アラートを送信するワークフローがあるとします。これはワークフローである可能性があります。

public override IEnumerable<WorkItem> Workflow() {
    // These would probably be injected from elsewhere
    var db = new DB();
    var emailServer = new EmailServer();

    // other workitems here

    var ci = new FindLowInventoryItems(db);
    yield return ci;

    if (ci.LowInventoryItems.Any()) {
        var email = new SendEmailToWarehouse("Inventory is low.", ci.LowInventoryItems);
        yield return email;
    }

    // other workitems here
}

CheckInventory と EmailWarehouse は WorkItem から派生したオブジェクトで、サブクラスが実装する抽象 Execute() メソッドを持ち、これらのアクションの動作をカプセル化します。ワークフロー フレームワークで Execute() メソッドが呼び出されます。Workflow() を列挙し、ワークアイテムの前後のイベントをラップし、イベント間で Execute を呼び出す WorkflowRunner クラスがあります。これにより、消費するアプリケーションは、キャンセル、作業項目のプロパティの変更など、作業項目の前後に必要なことを何でも行うことができます。

これらすべての利点は、タスクのコア ロジックを、作業を完了するための作業項目の観点から表現できることであり、かなり単純でほぼ手続き的な方法でそれを実行できることです。また、IEnumerable と、それをサポートする C# のシンタックス シュガーを使用しているため、サブワークフローを使用して操作する高レベルのワークフローのように、これらのワークフローを作成できます。たとえば、2 つの子ワークフローをインターリーブするだけの単純なワークフローを作成しました。

私の質問はこれです - 特に保守性の観点から、この種のアーキテクチャは合理的に見えますか? 私にとっていくつかの目標を達成しているようです-自己文書化コード（ワークフローは手続き的に読み取られるため、どのステップで何が実行されるかがわかります）、懸念の分離（在庫の少ないアイテムを見つけることは、倉庫に電子メールを送信することに依存しません）、など。また、この種のアーキテクチャには、私が見ていない潜在的な問題はありますか? 最後に、これは以前に試されたことがありますか?これを再発見しただけですか?

4

2 に答える 2

2

個人的には、これは「構築する前に購入する」決定です。書く前に買ってしまいます。

私はかなり大きな会社で働いており、そのお金で愚かになる可能性があるため、これを自分のために書いていて何かを買うことができない場合は、コメントを撤回します.

ここにいくつかのランダムなアイデアがあります：

おそらくファイルやデータベースから、起動時に読み込むことができる構成にワークフローを外部化します。

状態、遷移、イベント、およびアクションを備えた有限状態マシンのように見えます。

さまざまなフローをその場でカスタマイズできるように、さまざまなアクションをプラグインできるようにしたいと考えています。

特定のイベントが発生したときに通知を受け取りたいさまざまなサブスクライバーを登録できるようにしたいと思います。

その電子メール サーバーほどハードコードされたものはないと思います。それを必要とするイベントにプラグインできるように、それを EmailNotifier にカプセル化したいと思います。ブザー通知はどうですか？それとも携帯電話？ブラックベリー？同じアーキテクチャ、異なる通知機能。

人間との対話用のハンドラーを含めますか? 私が扱うすべてのワークフローは、人による処理と自動化された処理が混在しています。

データベース、他のアプリ、Web サービスなど、他のシステムに接続する予定はありますか?

難しい問題です。幸運を。

于 2009-01-16T01:08:34.533 に答える
0

@Erik：（私の回答の適用可能性に関するコメントに対処します。）独自のカスタムワークフローシステムを設計および構築するという技術的な課題を楽しんでいる場合、私の回答は役に立ちません。ただし、将来にわたってサポートする必要があるコードを使用して実際の WF の問題を解決しようとしている場合は、組み込みの WF システムを使用することをお勧めします。

ワークフローのサポートは現在、.Net フレームワークの一部であり、「Workflow Foundation (WF)」と呼ばれています。ダフィーモが「構築前に購入する」というコメントで指摘したように、独自のライブラリを作成するよりも、組み込みライブラリの使用方法を学ぶ方がほぼ確実に簡単です。

ワークフローは XAML で表現され、Visual Studio のデザイナーによってサポートされます。ワークフローには 3 つのタイプがあります (ウィキペディアから、以下のリンク)。

  • シーケンシャル ワークフロー(通常はフローチャート ベースで、1 つの段階から次の段階に進み、後戻りすることはありません)
  • ステート マシン ワークフロー(「状態」から「状態」への進行。これらのワークフローはより複雑で、必要に応じて前のポイントに戻ります)
  • ルール駆動型ワークフロー(Sequential/StateMachine ワークフローに基づいて実装。ルールはワークフローの進行を指示します)

ウィキペディア: Windows Workflow Foundation

MSDN: Workflow Foundation (WF) の概要

于 2009-01-16T05:10:36.820 に答える