:)
在过去的几周里，我观看并阅读了大量 MVVM Material ，似乎每个人都以一种或另一种方式做但没有详细说明的主要区别。我们是为每个 View 还是每个模型创建一个 ViewModel？
有一个问题，但我认为它不是 answered彻底。所以..
让我们以 Recipes 应用为例，其中我们有三个不同的 View :RecipesViewController、RecipeViewController 和 RecipeCell。我认为实现 MVVM 的正确方法是为每个 View 创建一个 ViewModel，而不是创建一个 RecipeModel 并在它们之间共享它。
这个例子可能足够基本，我们可能更喜欢一个 ViewModel，但它不正确，是吗？如果两者都可以接受，有人可以解释差异、缺点和好处吗？如果我们有一个网络层，那么只有 ViewModel 应该与之通信，对吗？
谢谢你。
最佳答案
当人们确实以正确的方式思考来实现它们时，模式和架构可能很难理解。
它们只是指导方针。它们为您提供了职责分离，您作为开发人员可以根据您的问题决定如何应用它们。以一种方式做它们可能比以另一种方式做它们更难，仅此而已。
模式无法解决您将要遇到的所有问题。
从实践中人们发现，在大多数情况下，View 更好。与单人沟通 ViewModel .我的经验已经证明，这确实使您的逻辑更清晰，因为它改变了 ViewModel可破单View调试和跟踪正在发生的事情可能会更难。如果您确实需要在 Views 之间共享一些状态和/或逻辑属于单个ViewModel想想怎么可以有两个ViewModels而不是一个并添加一个 Model共享该状态和逻辑并拥有 ViewModels共享那个对象。
一个 ViewModel可以与多个 Views 通信(而每个 View 都有一个 View 模型)。大多数时候如果你可以做一个ViewModel与单人沟通 View他们这样做。它使事情变得更容易。
对于复杂的相互关联的逻辑，有时只有一个 ViewModel每 View可能更难做到。通常你会分你的ViewModel在层次结构中，您将拥有一个 ParentViewModel和几个较小的细粒度 ChildViewModels .但是这些ChildViewModels可能必须与他们的 parent 或彼此之间进行交流。通过破解 ViewModels进入层次结构，您可以实现单个 ViewModel查看，但如果你不能不要强制自己。有时不这样做会更简单。
至少不要一开始就试图拥有一个 ViewModel为 View .使用迭代方法和重构。做一个更大的ViewModel并将其 Hook 到不同的 Views .稍后重构您的方式以打破 MainViewModel并试图让他们以更少的观点进行交流。
分享一个 Model之间ViewModels完全没问题。我认为Models可能是未充分利用的东西。人们确实尝试为 ViewModels 添加更多逻辑在它们之间创建耦合，而它们应该使用 Models反而。
您需要考虑的一件重要事情是 的划分介绍 和 型号 .在您的 上做更多工作型号 你会看到很大的好处。
如果你的例子你应该有一个 Recipe型号为 Recipe是您的 DomainModel并且应该有与配方相关的数据和行为。然后你会有一个 RecipeViewModel并且是您 的一部分介绍 并具有 Recipe 的演示逻辑.然后您将拥有您的 RecipeView这将连接到 RecipeViewModel它有责任拥有代表 Recipe 的实际 GUI 小部件。是 赠送 对用户使用react并调整它的小部件/控件以适应 RecipeViewModel 中的变化.
在 MVVM 中，Views平时不联系Models .他们确实与 ViewModels 通信然后与 Models 通信.
我看到的一个大问题是人们对待 Models作为他们存储到数据库的东西和其他所有内容( Views 、 ViewModels 、 Services 等)作为应用程序。这是一个很大的缺陷。如果您还没有阅读 Domain Driven Design我强烈推荐它，因为它详细解释了拥有良好的值(value) Models .
以下是一些资源:
关于ios - (MVVM) 每个 View 或每个模型的 View 模型？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/56163267/