iOS MVVM 中视图控制器之间的通信答案

【问题标题】：Communication between View Controllers in iOS MVVMiOS MVVM 中视图控制器之间的通信
【发布时间】：2020-09-15 05:38:45
【问题描述】：

我正在开发一个简单的应用程序来在 iOS 中试用 MVVM。我的应用程序中只有两个屏幕。 Screen A 显示内容，用户可以点击settings 按钮拉出screen B。 Screen B 允许用户更改影响screen A 显示内容方式的设置。

我应该如何将screen B 中所做的更改传达给screen A，以便screen A 可以根据设置更改重新显示内容？在 MVC 中，我将使用协议/委托将 ViewControllerB 中所做的更改传达给 ViewControllerA。由于视图控制器可以直接访问模型，我可以在委托调用中传递更新的模型。在 MVVM 中，ViewModelB 到 ViewModelA 或 ViewControllerB 到 ViewControllerA 之间是否会发生通信（如 MVC）。
如果视图控制器之间发生通信，那么ViewControllerB 真正传递给ViewControllerA 的是什么？ ViewModelA?如果是这样，ViewControllerB 知道ViewModelA 是否会破坏减少视图控制器责任/知识的目的？

感谢您花时间阅读问题！

【问题讨论】：

在我看来（我的意思是“意见”），模型类应该代表应用程序中的当前共享状态。视图模型应该与底层模型通信以获取/设置与其视图控制器相关的状态部分。换句话说，我不喜欢在与 UI 相关的类之间传递任何重要的东西。

标签： ios mvvm

【解决方案1】：

在这种情况下，我会按如下方式设计数据流：

ViewModelA 和ViewModelB 都与模型层中的某个实体（MVVM 中的第一个 M）进行通信。此类实体通常称为“服务”并包含持久性/网络逻辑。
当用户打开ViewControllerB 并更改某些设置时，ViewModelB 会对模型进行相应的更改。
ViewModelA 观察对同一模型的更改（通过 KVO、NotificationCenter、响应式发布者或良好的旧委托模式，任何最适合您的方式）并根据需要通过更新 ViewControllerA 来对它们做出反应。

这样，您的两个视图模型都不需要相互了解，并且您的模型层就像它们的单一事实来源一样。

【讨论】：

感谢您的回复！这是有道理的，我绝对喜欢“单一真理来源”的哲学。如果您不想在本地存储中存储任何内容，但多个屏幕正在更改同一模型，那该怎么办？示例：当用户在多个屏幕上填写表单时。在这种情况下你会选择单例吗？
是的，我个人对这种情况的偏好是让这些多个屏幕的视图模型与模型的同一个实例一起工作。您可以通过使用单例（我通常避免这样做，因为它使单元测试更难）或通过将服务对象的相同实例注入视图模型（我喜欢为此使用协调器模式，所以我的 MVVM 变为MVVM-C)。
是的，我的偏好是尽可能避免使用单例，因此在这些情况下我将学习协调模式。过去我大多避免采用这种模式，因为它对我的一些应用程序来说似乎有点过头了，但在某些情况下，它确实提供了一个优于单例的优雅解决方案。谢谢您的答复！欣赏！