c# - 驱动 MVVM 应用程序

Question

给定任何具有超过 5 个 View 和 View 模型的中间 MVVM 应用程序，是否有任何推荐的设计模式来说明如何为此类应用程序搭建脚手架？

现在我通常有一个在 App.OnStartup 中创建的 Controller :

设置主视图

注入(inject) subview (通常我有一个带有状态栏和导航的 MainWindow，它有“内部窗口”)

处理 View 和 View 模型的结合。

处理导航(从 View A 到 View B)

支持面包屑导航(以及典型的 NavigationService.GoBack() 之类的东西)

我相信已经有很好的设计模式，但我没有听说过或读过它们。

所以问题是:
是否有任何普遍接受的模式来处理 View 模型和 View 的耦合(设置数据上下文)以及 View 之间的导航？

在我看来， View 优先(在 XAML 中设置 DataContext)和 View 模型优先(让 View 模型通过 DI/IOC 获得 View 注入(inject))都不是很好，因为它们在 View 和 View 模型之间建立了依赖关系。

Plain MVVM 对如何设置整个 MVVM 机器没有任何假设。
我只是想知道这个很常见的问题没有“现成的”解决方案。
我相信 Controller 被广泛使用。其他人如何解决这个问题？

Answer 1

一些需要考虑的设计模式是Inversion of Control (IoC)和 Event Aggregator .

对于 C#/MVVM，Caliburn Micro Framework (是其中之一)使 IoC 和事件聚合器更容易。

您正确地确定了 MVVM 的一个核心问题，即没有现成的解决方案可以真正将 ViewModel 与 View 解耦。 ViewModel 是专门为与 Views 配对而构建的，这是一个核心概念。问题归结为如何管理 ViewModel/View 配对的实例。

View first 方法假设 View 知道并可以根据需要实例化 ViewModel——这对 SoC 来说是一个问题，因为任何 View 类现在都有多个职责；启动 ViewModel 并处理 UI。

首先查看模型很困难，因为它通常会导致破坏 MVVM 的主要租户之一——VM 应该可以在没有任何关联 View 的情况下进行测试。

通常，这就是 IoC 的用武之地。 IoC 通常驻留在 View 层中(这是为了允许它根据需要访问所有 View 和 ViewModel 类)它不需要是 View 本身。将您的 IoC 管理器视为 Controller 通常会更好——这会导致 MVCVM 的伪模式。这个“ Controller ”的唯一目的是为任何需要它的人提供 View 和 ViewModel 实例配对。

事件聚合器模式确实对此有所帮助，因为 ViewModel 和 View 中的类不再需要担心它们与谁配对，并且只能与它们自己级别的其他类交互。一个特定的 View 模型不需要关心是谁发送了“更新加载进度”事件，它只需要负责通过设置它的进度属性来处理事件的结果。