Question

我正在构建一个使用IoC容器进行依赖注入的WPF应用程序（在我的情况下是MEF）。该应用程序包含几个我们正在建模为WF工作流程的详细流程。但是，一些（并非所有）活动依赖于由IoC容器管理的服务和其他组件。我看到了一些可能的方法来实现这一点，但它们似乎都没有遵循最佳实践。他们是：

使用构造函数中的服务定位器或每个活动的Execute方法进行定位并设置依赖项。就个人而言，我不喜欢服务定位器，因为我认为他们违反了DI的租户之一，其中代码不知道依赖关系的创建位置和方式。它还使活动不易测试（或者至少为测试过程增加了几个步骤）。我在StackOverflow和CodePlex上看到了一些使用WF服务扩展的示例，它基本上以相同的方式工作。我没有使用WF服务，所以这不是一个选择。
导出每个活动并让工作流导入它们。这将确保容器满足所有我们需要它们之前的依赖关系，但意味着我们没有构建它们 XAML中的工作流程。
导出工作流并让它导入所需的依赖项活动。然后我必须将依赖项设置为要消耗的活动的参数。这不仅会导致结果在工作流程中的很多开销代码，但它现在意味着工作流需要知道所有的依赖关系活动。如果活动发生变化，添加或删除，我现在拥有更改工作流程以适应任何更改的依赖关系。
采用与＃3相同的方法，而不是导出工作流，有一个导出的控制类，导入所有依赖项并将它们设置为工作流的输入参数本身。每个活动都会拉动它所需的依赖关系。这个与＃3有同样的问题，需要维护更多的代码。

所以，我的问题是，我应该采取什么方法？（即你采取了什么方法？）

我也假设上面的列表并不全面，希望有人会建议一个更好的选择，如果存在的话。

THX！

Answer 1

方法二似乎是最充足的。您可以在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设计过程与基础活动分开。

使用IoC编写工作流程

1 个答案: