2

いくつかのプロセスを非同期的に開始し、非同期イベントが到着したときにウェイクアップする必要がある、カスタムの Windows Workflow Foundation アクティビティを作成しています。

私が見つけたすべてのサンプル (たとえば、Kirk Evans によるもの) には、ほとんどの作業を行うカスタム ワークフロー サービスが含まれており、アクティビティによって作成されたキューにイベントがポストされます。その主な理由は、[WF 以外のスレッドから機能する] イベントを投稿する唯一の方法が WorkflowInstance.EnqueueItem であり、アクティビティがワークフロー インスタンスにアクセスできないため、イベントを投稿できないことです。 (非同期操作の結果を受け取る非 WF スレッドから)。

この設計は好きではありません。機能が 2 つに分割され、新しいアクティビティ タイプが追加されたときにホストにサービスを追加する必要があるからです。醜い。

そこで、アクティビティの非同期イベント ハンドラーから呼び出し、さまざまな非同期アクティビティで再利用できる次の汎用サービスを作成しました (エラー処理は省略されています)。

class WorkflowEnqueuerService : WorkflowRuntimeService
{
    public void EnqueueItem(Guid workflowInstanceId, IComparable queueId, object item)
    {
        this.Runtime.GetWorkflow(workflowInstanceId).EnqueueItem(queueId, item, null, null);
    }
}

アクティビティ コードでは、このサービスへの参照を取得して保存し、非同期操作を開始し、完了したら、このサービスを使用してイベントをキューに投稿できます。この利点 - すべてのアクティビティ固有のコードをアクティビティ内に保持し、アクティビティの種類ごとに新しいサービスを追加する必要がありません。

しかし、公式およびインターネットのサンプルがそれを行っているのを見ると、再利用不可能なサービスに特化しています。このアプローチが問題ないかどうかを確認したいですか、それともここでいくつかの問題を引き起こしていますか?

4

2 に答える 2

1

ここには、ワークフローの永続性に関して潜在的な問題があります。

データベースでランタイムに永続化される長時間実行ワークフローを作成すると、これらのワークフローを再起動できます。これらのワークフローは、それらを再ロードする外部イベントが発生するまでメモリに再ロードされません。そこでは、イベント自体をトリガーする責任がありますが、リロードされるまではできません。そして、キャッチ22があります:-(

これを行う適切な方法は、外部サービスを使用することです。そして、これはコードを2つの場所に分割するように感じるかもしれませんが、実際にはそうではありません。その理由は、ワークフローが全体像、つまりIEが何をすべきかを担当しているためです。また、ランタイムサービスは、実際の実装またはその実行方法を担当します。そうすれば、理由と時期の部分を変更せずに、方法を変更できます。

于 2009-01-13T14:22:23.713 に答える
0

フォローアップ-すべての理由に関係なく、サービスを使用して「実行する必要がある」理由は、.NET 4.0によって直接サポートされます。これにより、アクティビティの永続性を一時停止しながら、非同期作業を開始するためのクリーンな方法が提供されます。アクティビティ。

詳細について は、 http：//msdn.microsoft.com/en-us/library/system.activities.codeactivitycontext.setupasyncoperationblock （VS.100）.aspx を参照してください。

于 2009-06-22T00:37:15.400 に答える