Question

我一直在比较Unity和MEF（用于Prism）并且正在向MEF迈进。唉，最近我看到了Unity很酷的运行时依赖性解析 - 如果我想添加一个模块，我应该使用view添加它的ServiceLocator类型，如果我有一个依赖构造函数来说明{{1} }，Unity将为我初始化它，以及VM的依赖项（在其他服务和模块中）。

MEF是否支持这种行为？

感谢。

Answer 1

现在让我们忽略Unity和MEF，看看你的描述。

如果我有一个描述view model的依赖构造函数，Unity会为我初始化它，以及VM的依赖项（在其他服务和模块中）。

此机制称为依赖注入（DI），是控制反转（IoC）原则的实现。另请注意，DI与服务地点（SL）不同。

您的特定示例称为构造函数注入，其中依赖项 注入到正在构造的类型中，因此：

public MyView(MyViewModel viewModel) { }

是构造函数注入的站点。现在让我们看看两种不同的容器技术：

Unity是传统意义上的IoC容器。您可以在运行时注册已知部件，这些部件可以构建目录，当您从容器中请求部件时，它将自动解析所需的依赖关系。

MEF围绕未知部分的发现和组合而构建，即，它通过从导出提供程序（目录或其他提供程序）构建列表来构建它的容器。当您请求编写零件时，默认情况下会选择无参数构造函数，例如：

public MyView() { }

除非，否则使用[ImportingConstructor]属性修饰目标构造函数，这允许MEF选择适当的构造函数，并解析所有依赖项：

[ImportingConstructor]
public MyView(MyViewModel viewModel) { }

另请注意，MEF通过[Import]和[ImportMany]属性支持属性注入：

[Import]
public MyViewModel ViewModel { get; set; }

虽然，我更喜欢使用构造函数注入，因为它更好地描述了类所需的依赖关系。

现在，在撰写本文时，这适用于使用归属编程模型的MEF 1.0。使用MEF 2.0（以及通过MEFContrib），有一些机制可以支持基于注册和基于约定的编程模型。

简而言之，是您可以使用MEF进行依赖注入。

MEF VS Unity - 依赖于运行时解析

1 个答案: