Prism，用Unity连接Views和ViewModels，试图理解它

使用 Unity 创建视图和视图模型

使用 Unity 作为依赖项注入容器类似于使用 MEF，基于属性的注入和基于构造函数的注入都是 支持的。主要区别在于这些类型通常是 在运行时没有隐式发现；相反，他们必须是 已向容器注册。

通常，您在视图模型上定义一个接口，以便视图 模型的具体具体类型可以与视图解耦。为了 例如，视图可以通过以下方式定义其对视图模型的依赖关系： 构造函数参数，如此处所示。 C＃

public QuestionnaireView() 
{
    InitializeComponent(); 
}

public QuestionnaireView(QuestionnaireViewModel viewModel) : this() 
{
    this.DataContext = viewModel;
}

默认无参数 构造函数是允许视图在设计时工作所必需的 工具，例如 Visual Studio 和 Expression Blend。

或者，您可以在 视图，如此处所示。 Unity将实例化所需的视图模型 并在视图实例化后调用属性设置器。 C＃

public QuestionnaireView() 
{
    InitializeComponent(); 
}

[Dependency] 
public QuestionnaireViewModel ViewModel 
{
    set { this.DataContext = value; } 
}

视图模型类型注册到Unity容器中，如图 这里。 C＃

IUnityContainer container;
container.RegisterType<QuestionnaireViewModel>();

然后可以通过容器实例化视图，如图所示 这里。 C＃

IUnityContainer container;
var view = container.Resolve<QuestionnaireView>();

1. 如果我省略了有关注册 ViewModel 和实例化 View 的代码的最后一部分，并且仅使用此处将 ViewModel 挂接到 View 的两种方法之一（使用构造函数或使用属性），则似乎 ViewModel 和 View似乎一切正常。那么注册ViewModel和实例化View的代码需要什么呢？

2. 第一个示例使用构造函数挂钩 View 和 ViewModel，完全没有提及 Unity，那么这里实际上使用了 Unity 吗？

3. 与基于构造函数的注入相比，使用基于属性的注入是否有任何优点，或者它们是否完全相同？

4. 文本的第一部分说“*通常，您在视图模型上定义一个接口，以便视图模型的特定具体类型可以与视图解耦”，然后给出一个示例。然而这个例子根本没有提到接口。这是怎么回事，我错过了什么吗？

回答问题 1 和 4

在您的示例中，视图模型的类型为QuestionnaireViewModel，这是一个具体的类。由于它是一个具体的类，因此当您使用以下命令解析视图时container.Resolve<QuestionnaireView>()，unity将通过调用为您实例化视图模型container.Resolve<QuestionnaireViewModel>()在幕后。

在这种情况下，注册视图模型是多余的。但是，当使用依赖注入时，您通常希望使用接口而不是类，因此您的构造函数将如下所示：

public QuestionnaireView(IQuestionnaireViewModel viewModel)
{
    this.DataContext = viewModel;
}

现在您的构造函数接收一个接口而不是一个类作为参数，Unity 不知道您要使用该接口的哪个实现。为了告诉 Unity，您需要将视图模型注册到容器：

container.RegisterType<IQuestionnaireViewModel, QuestionnaireViewModel>();

所以现在当你解析你的视图时，Unity将查找它应该使用哪个类作为实现IQuestionnaireViewModel，看到它是QuestionnaireViewModel并使用它。

回答问题2

正在使用Unity，因为为了让构造函数获取其参数，您需要使用容器解析视图。如果您自己实例化视图，则不会使用 Unitynew QuestionnaireView()，即不会发生构造函数或属性注入。

回答问题3

我认为这主要是关于什么更舒适以及您需要在哪里使用注射构件的问题。很多时候，您只想在构造函数中设置局部变量，而不是创建仅用于执行注入的属性。

不过，属性注入的一个好处是您可以使用container.BuildUp()使用创建的实例的方法new而不是container.Resolve<>()。这样，即使在创建之后，您也可以将成员注入到属性中 - 这是构造函数注入无法做到的事情。