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

Question

我一直在比较Unity和MEF(用于Prism)并且正在向MEF迈进.唉,最近我看到了Unity很酷的运行时依赖性解析 - 如果我想添加一个模块,我应该view使用它添加它的类型ServiceLocator,如果我有一个依赖构造函数说明view model,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进行依赖注入.