在 MVVM 中解析 Prism 服务答案

【问题标题】：Resolving Prism Services in MVVM在 MVVM 中解析 Prism 服务
【发布时间】：2013-02-01 13:05:11
【问题描述】：

尝试在容器中解析我存储的服务对象（主要是单例接口），

有一个Domain Module，它的ViewModels会使用Services Module的Services。

您建议在哪里以及如何解决这个问题，在域 Module 内还是在域模块的 ViewModels 内解析？

如果我可以在 ViewModel 的构造函数中执行此操作，以下代码是否足够，在服务注册后，如果我不想执行此操作：

    public DetailsViewModel(IWService wSvc,)
    {
        wService = wSvc;
    }

在“视图模型”中获取服务对象（存储在容器中）的最佳方法是什么？

我在这里提供的只是一个示例。感谢您的帮助

【问题讨论】：

只要你的视图模型（DetailsViewModel）被统一容器解析，你上面的代码应该在视图模型中为你提供服务。您所拥有的是我所看到的 Prism 应用程序创建的标准方式。如果您的视图模型不是由容器创建的，您需要自己将服务传递给视图模型的构造函数。我刚刚使用 Prism 编写了一个应用程序，并且我在很大程度上放弃了 MVVM，转而采用更类似于 MVP 的方法，因为我发现没有演示者或控制器类的 VM（视图模型）的整个概念非常混乱。
@Jay 感谢您提供的信息，很抱歉当时我不在电脑旁，我仍在处理它并尝试理解和利用一些较暗的部分，我喜欢它我的代码缺少一些我正在尝试修复的部分。 :)

标签： c# mvvm prism unity-container

【解决方案1】：

我建议您的 ViewModel 通过构造函数的依赖注入获取它们使用的服务。无论您决定采用哪种方法，您都应该记住，主要概念之一是测试 ViewModel 的能力。通常，这将涉及能够为您的 ViewModel 提供服务的模拟实现，以独立于这些服务来测试它们的行为。如果你使用构造函数注入，你可以简单地创建你的模拟服务，然后将它们传递给你的 ViewModel 的构造函数来测试你是否要编写单元测试。即使您此时不打算编写单元测试，我认为这是养成遵循某种设计方案的习惯的正当理由。

public class SomeViewModel
{
    private IEventAggregator events;
    private ISomeService someService;

    public SomeViewModel(IEventAggregator events, ISomeService someService)
    {
        this.events = events;
        this.someService = someService;
    }
}

【讨论】：

我遇到了与您提供的相同点，但要问一个简单的问题：我没有获得服务，而是尝试通过构造函数获取 IUnityContainer，然后立即调用后来定义的 FetchServices 方法我在那里定义了我的服务，可以吗？或者在这种情况下是否建议将 Container 设为单例？
@LastBye 不，你刚才描述的不是一个好主意。您基本上是在制作单例或服务位置样式模式，这在某种程度上否定了依赖注入的目的。您可能想查找“Composition Root”，虽然我不完全同意，但它解释了为什么您不想做您刚才提到的事情
@LastBye 简而言之，尝试将容器的使用限制在每个模块的入口点。我会将 IUnityContainer 注入到您的 IModule 的（实现）构造函数中。然后，注册您的类型并在 Initialize 方法中解析其组件，至少对于 Unity。通常，您解析的其他类型或注入其他类型的其他类型应该能够将它们的依赖项注入构造函数。
+1s，明白你的意思，将 FetchServices 从构造函数中分离出来（但不是单例容器，它也会从构造函数中调用）怎么样？这可能对更快的类生成和分类有所帮助。（我的想法的第一部分）
把它和构造函数分开是什么意思？更快的生成和分类是什么意思？我会避免直接在您的视图模型中使用 ServiceLocator 或容器。我还将避免使用 DependencyAttribute ( [Dependency] ) 进行属性注入，因为构造函数显示一个类在手动创建时具有明确的依赖关系。但是，您可以使用构造函数重载，例如，如果您想要传递或多或少的可选依赖项的选项。 ctor 参数还有一个 [Optional] 属性。（然后检查是否为空）