MVVM和服务模式

我正在使用MVVM模式构建WPF应用程序。现在，我的视图模型调用服务层以检索模型（与视图模型无关）并将其转换为视图模型。我正在使用构造函数注入将所需的服务传递给viewmodel。

它易于测试，并且适用于几乎没有依赖关系的viewmodel，但是当我尝试为复杂模型创建viewModels时，我就有了一个构造函数，其中注入了很多服务（一个用于检索每个依赖关系和所有可用值的列表）绑定到itemsSource）。我想知道如何处理这样的多种服务，并且仍然拥有一个可以轻松进行单元测试的视图模型。

我在考虑一些解决方案：

1. 创建一个包含所有可用服务作为接口的服务单例（IServices）。示例：Services.Current.XXXService.Retrieve（），Services.Current.YYYService.Retrieve（）。这样，我就没有一个包含大量服务参数的庞大构造函数。

2. 为viewModel使用的服务创建外观，并将此对象传递到我的viewmodel的ctor中。但是，然后，我必须为我的每个复合视图模型创建一个外观，这可能会有点多...

您认为实现这种架构的“正确”方法是什么？

实际上，这两种解决方案都是不好的。

创建一个包含所有可用服务作为接口的服务单例（IServices）。示例：Services.Current.XXXService.Retrieve（），Services.Current.YYYService.Retrieve（）。这样，我就没有一个包含大量服务参数的庞大构造函数。

本质上，这是服务定位器模式，它是一种反模式。如果这样做，您将无法不查看视图模型的私有实现而了解视图模型实际依赖的内容，这将使测试或重构变得非常困难。

为viewModel使用的服务创建外观，并将此对象传递到我的viewmodel的ctor中。但是，然后，我必须为我的每个复合视图模型创建一个外观，这可能会有点多...

这不是反模式，而是代码的味道。本质上，您是在创建一个参数对象，但PO重构模式的重点是处理经常在许多不同地方使用的参数集，而此参数只能使用一次。就像您提到的那样，它会造成很多代码膨胀，但并没有真正的好处，并且不能与很多IoC容器配合使用。

实际上，以上两种策略都忽略了整个问题，即视图模型与服务之间的耦合度过高。简单地将这些依赖项隐藏在服务定位器或参数对象中并不会真正改变视图模型所依赖的其他对象数量。

想想如何对这些视图模型之一进行单元测试。您的设置代码有多大？为了使它起作用，需要初始化几件事？

从MVVM开始的很多人都试图为整个屏幕创建视图模型，这从根本上来说是错误的方法。MVVM都是关于合成的，具有许多功能的屏幕应该由几种不同的视图模型组成，每种视图模型仅取决于一个或几个内部模型/服务。如果他们需要彼此通信，则可以通过pub / sub（消息代理，事件总线等）进行通信。

您实际需要做的是重构视图模型，以减少依赖。然后，如果需要聚合“屏幕”，则可以创建另一个视图模型以聚合较小的视图模型。这种聚合视图模型本身并不需要做很多事情，因此反过来也很容易理解和测试。

如果您正确执行了此操作，那么仅通过查看代码就应该显而易见，因为您将拥有简短，简洁，特定且可测试的视图模型。

我可以写一本关于这本书...实际上我是;）

首先，没有通用的 “正确”方法来做事。您必须考虑其他因素。

您的服务可能过于精细。使用提供特定ViewModel或相关ViewModel集群的接口的Facades将服务包装起来可能是一个更好的解决方案。

更简单的方法是将服务包装到所有视图模型使用的单个Facade中。当然，对于一般情况而言，这可能是一个非常大的界面，具有许多不必要的功能。但是我想说这与处理系统中每条消息的消息路由器没有什么不同。

实际上，我看到的许多体系结构最终演变为围绕诸如Event Aggregator模式之类构建的消息总线。在这里进行测试很容易，因为您的测试类仅向EA注册了一个侦听器并触发相应的事件作为响应。但这是一个先进的方案，需要一段时间才能发展。我说从统一的门面开始，然后从那里开始。

为什么不将两者结合？

创建一个外观，并放置您的视图模型使用的所有服务。这样，您就可以为所有视图模型使用单一外观，而无需输入不良的S字。

或者，您可以使用属性注入而不是构造函数注入。但是，然后，您需要确保已正确注入了它们。