2

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

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

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

我还假设上面的列表并不全面，希望有人能提出更好的选择，如果存在的话。

谢谢！

4

1 回答 1

0

方法二似乎是最合适的。您可能会在 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 回答