c# - Prism，将 Views 和 ViewModels 与 Unity 连接起来，试图理解它

Question

Creating the View and View Model Using Unity

Using Unity as your dependency injection container is similar to using MEF, and both property-based and constructor-based injection are supported. The principal difference is that the types are typically not implicitly discovered at run time; instead, they have to be registered with the container.

Typically, you define an interface on the view model so the view model's specific concrete type can be decoupled from the view. For example, the view can define its dependency on the view model via a constructor argument, as shown here. C#

public QuestionnaireView() 
{
    InitializeComponent(); 
}

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

The default parameter-less constructor is necessary to allow the view to work in design-time tools, such as Visual Studio and Expression Blend.

Alternatively, you can define a write-only view model property on the view, as shown here. Unity will instantiate the required view model and call the property setter after the view is instantiated. C#

public QuestionnaireView() 
{
    InitializeComponent(); 
}

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

The view model type is registered with the Unity container, as shown here. C#

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

The view can then be instantiated through the container, as shown here. C#

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

1. 如果我省略了有关注册 ViewModel 和实例化 View 的代码的最后一部分，而只使用此处将 ViewModel 挂接到 View 的两种方法中的任何一种(使用构造函数或使用属性) ViewModel 和 View 似乎一切正常。那么注册ViewModel和实例化View的代码需要什么？

2. 第一个示例，使用构造函数连接 View 和 ViewModel，完全没有提到 Unity，那么这里实际上使用的是 Unity 吗？

3. 使用基于属性的注入(inject)与基于构造函数的注入(inject)相比有什么优势吗？还是它们完全一样？

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

Answer 1

回答问题 1 和 4

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

在这种情况下，注册您的 View 模型是多余的。但是，在使用依赖注入(inject)时，您通常希望使用接口(interface)而不是类，因此您的构造函数看起来像这样:

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

现在您的构造函数接收接口(interface)而不是类作为参数，Unity 不知道您要使用接口(interface)的哪个实现。要告诉 Unity，您需要将 View 模型注册到容器中:

container.RegisterType<IQuestionnaireViewModel, QuestionnaireViewModel>();

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

回答问题2

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

回答问题3

我认为这主要是什么更舒适以及您需要在何处使用注入(inject)成员的问题。很多时候，您只想在构造函数中设置一个局部变量，而不是仅仅为了执行注入(inject)而创建一个属性。

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