2

依存性注入 (私の場合は MEF) に IoC コンテナーを使用する WPF アプリケーションを構築しています。アプリケーションには、WF ワークフローとしてモデル化しているいくつかの詳細なプロセスが含まれています。ただし、アクティビティの一部 (すべてではない) は、IoC コンテナーによって管理されるサービスやその他のコンポーネントに依存しています。これを達成するためのいくつかの方法が考えられますが、どれもベストプラクティスに従っているようには見えません。彼らです：

  1. 各アクティビティのコンストラクターまたは Execute メソッドで service-locator を使用して、依存関係を見つけて設定します。個人的には、依存関係がどこでどのように作成されるかをコードが認識できない DI のテナントの 1 つに違反していると思われるため、サービス ロケーターは好きではありません。また、アクティビティのテストが難しくなります (または、少なくともテスト プロセスにいくつかの手順が追加されます)。StackOverflow と CodePlex で、基本的に同じように機能する WF Services 拡張機能を使用する例をいくつか見てきました。私は WF サービスを使用していないため、これはオプションではありません。
  2. 各アクティビティをエクスポートし、ワークフローでそれらをインポートします。これにより、必要になる前にコンテナーがすべての依存関係を満たしていることが保証されますが、XAML でワークフローを構築していないことを意味します。
  3. ワークフローをエクスポートし、アクティビティに必要な依存関係をインポートします。次に、アクティビティが消費するパラメーターとして依存関係を設定する必要があります。これにより、ワークフローに大量のオーバーヘッド コードが発生するだけでなく、ワークフローがすべてのアクティビティの依存関係に関する知識を必要とすることになります。アクティビティが変更、追加、または削除された場合、依存関係の変更に対応するためにワークフローを変更する必要があります。
  4. ワークフローをエクスポートする代わりに、制御クラスをエクスポートし、すべての依存関係をインポートし、それらをワークフロー自体の入力パラメーターとして設定することを除いて、#3 と同じアプローチを取ります。各アクティビティは、必要な依存関係をプルします。これには #3 と同じ問題がすべてあり、維持するコードが増えます。

だから、私の質問は、私はどのようなアプローチを取るべきですか? （つまり、どのようなアプローチをとったのですか？）

また、上記のリストは包括的ではないと想定しており、誰かがより良いオプションを提案してくれることを願っています.

どうも！

4

1 に答える 1

0

アプローチ2が最も適切なようです。xamlでアクティビティ宣言を使用する場合があります。これは、後で実際のアクティビティ宣言をインポートするために使用されます。

編集： 

<wf:Workflow.Activities></activities:PassThrough UserId="mstewart"></wf:Workflow.Activities>

そして、あなたはそれらの行の中に何かを持つことができます 

interface IActivityInfo
{
  IActivity ImportActivity();
}
interface IActivity<TActivityInfo> where TActivityInfo : IActivityInfo
{
  IActivityInfo Info { get; }
}

class PassThrough : IActivityInfo
{   
  public IActivity ImportActivity(){ return ServiceLocator.Current.GetInstance<IActivity<PassThrough>>(); }
}

[Export(typeof(IActivity<PassThrough>))]
class PassThroughActivity : IActivity<PassThrough>
{
}

このアプローチにより、xamlの設計プロセスを基礎となるアクティビティから簡単に分離できます。

于 2012-10-17T11:08:14.830 に答える