：）
在过去的几周中，我观看并阅读了许多MVVM材料，似乎每个人都以一种或另一种方式做了但没有详细说明的重大差异。我们是按视图还是按模型创建ViewModel？
有一个问题，但是我不认为它的answered会很彻底。所以..
例如，以“食谱”应用为例，我们拥有三个不同的视图：RecipesViewController，RecipeViewController和RecipeCell。我认为实现MVVM的正确方法是为每个视图创建一个ViewModel，而不是创建RecipeModel并在它们之间共享它。
此示例可能已经足够基础，我们可能更喜欢一个ViewModel，但这是不正确的，对吗？如果两者都可以接受，那么有人可以解释这些差异，缺点和好处吗？如果我们有网络层，则只有ViewModel可以与之通信，对吧？
谢谢。
答案 0 :(得分：2)
当人们确实以正确的方式思考以实现它们时，模式和体系结构可能很难理解。
它们只是准则。它们使您分担责任，而您作为开发人员则根据您的问题决定如何应用它们。一种方式做起来要比另一种方式做起来难，而且就差不多了。
没有一种模式可以解决您将要遇到的所有问题。
从实践中人们发现，在大多数情况下，View与单个ViewModel进行通信会更好。我的经验证明，这确实使您的逻辑更清晰，因为ViewModel的几个更改可能会破坏单个View，并且调试和跟踪正在发生的事情可能会更加困难。如果确实需要在属于单个Views的{{1}}之间共享某些状态和/或逻辑，请考虑一下如何使用两个ViewModel而不是一个并添加一个{{1} }共享状态和逻辑，并让ViewModels共享该对象。
Model可以与多个ViewModels通信（而每个View都有一个ViewModel）。在大多数情况下，如果您可以使一个ViewModel与一个Views进行通信，他们就会这样做。它使事情变得容易。
对于复杂的相互关联的逻辑，有时每个ViewModel只有一个View可能更难做到。通常，您将ViewModel划分为层次结构，其中将有一个View和几个较小的更细粒度的ViewModel。但是这些ParentViewModel可能必须与其父级或彼此之间进行通信。通过将ChildViewModels分解为层次结构，可以为View实现单个ChildViewModels，但是如果您不能强迫自己的话。有时，不这样做比较简单。
至少首先不要尝试为ViewModels使用单个ViewModel。使用迭代方法和重构。增大一个ViewModel，然后将其挂接到其他View。稍后重构您的方法，将ViewModel分解为较小的部分，并尝试使它们以较少的视图进行通信。
在Views之间共享一个MainViewModel很好。我认为Model可能是未充分利用的东西。人们确实尝试向ViewModels添加更多逻辑，从而在他们之间使用耦合，而应该使用Models。
您需要考虑的重要一件事是 演示文稿 和 模型 的划分。在您的 模型 上进行更多工作，您将看到很多好处。
如果您的示例是DomainModel，则应该有ViewModels模型，因为Models是Domain Driven Design，并且应该具有与配方相关的数据和行为。然后，您将拥有一个Recipe，并且是您的 演示文稿 的一部分，并且具有Recipe的演示文稿逻辑。然后，您将把RecipeViewModel钩到Recipe上，该RecipeView负责使实际的GUI窗口小部件代表RecipeViewModel的呈现方式 给用户并做出反应并调整其小部件/控件以适应Recipe中的更改。
在MVVM中，RecipeViewModel通常不与Views通信。他们确实与Models通信，然后与ViewModels通信。
我看到的一个大问题是，人们将Models视为他们存储到数据库中的东西以及其他所有东西（Models，Views，ViewModels等）。 ）作为应用程序。那是一个很大的缺陷。如果您还没有读过https://martinfowler.com/eaaDev/uiArchs.html，我强烈推荐它，因为它详细解释了拥有Services的价值。
以下是一些资源：