Nik*_*nov 0 design-patterns mvvm ios
:)
在过去的几周中，我观看并阅读了大量 MVVM 材料，似乎每个人都以一种或另一种方式进行了重大差异，但没有详细说明。我们是为每个视图还是每个模型创建一个 ViewModel？
让我们以 Recipes 应用为例，其中我们有三个不同的视图：RecipesViewController、RecipeViewController 和 RecipeCell。我认为实现 MVVM 的正确方法是为每个视图创建一个 ViewModel，而不是创建一个 RecipeModel 并在它们之间共享它。
这个例子可能足够基本，我们可能更喜欢一个 ViewModel，但它不正确，是吗？如果两者都可以接受，有人可以解释差异、缺点和好处吗？如果我们有一个网络层，那么只有 ViewModel 应该与之通信，对吗？
谢谢你。
当人们确实以正确的方式思考来实现它们时，模式和架构可能很难理解。
它们只是指导方针。它们为您提供了职责分离，您作为开发人员可以根据您的问题决定如何应用它们。以一种方式做它们可能比以另一种方式做它们更难，仅此而已。
模式无法解决您将要遇到的所有问题。
从实践中人们发现，在大多数情况下，aView与单个通信更好ViewModel。我的经验证明，这确实使您的逻辑更清晰，因为更改两个ViewModel可能会破坏单个，View并且调试和跟踪正在发生的事情可能会更难。如果您确实需要在Views属于单个的状态和/或逻辑之间共享某些状态和/或逻辑，请ViewModel考虑如何拥有两个ViewModels而不是一个并添加一个Model来共享该状态和逻辑并ViewModels共享该对象。
AViewModel可以与多个通信Views（而每个 View 都有一个 ViewModel）。大多数时候，如果你可以让一个人ViewModel与一个View人交流，他们就会这样做。它使事情变得更容易。
对于复杂的相互关联的逻辑，有时只有一个ViewModelperView可能更难做到。通常你会ViewModel在层次结构中划分你的层次结构，在那里你会有一个ParentViewModel和几个更小的更细粒度的ChildViewModels. 但这些ChildViewModels可能必须与他们的父母或彼此之间进行通信。通过打破ViewModels层次结构，您可以实现ViewModelView的单一化，但如果您不能做到，也不要勉强自己。有时不这样做更简单。
至少不要从尝试拥有一个ViewModelfor 开始View。使用迭代方法和重构。使一个更大ViewModel并将其挂钩到不同的Views. 稍后重构您的方式，将它们MainViewModel分解为更小的视图，并尝试使它们以更少的视图进行通信。
Model在两者之间共享一个ViewModels完全没问题。我认为这Models可能是未充分利用的东西。人们确实尝试ViewModels在他们应该使用的时候添加更多的逻辑来创建它们之间的耦合Models。
您需要考虑的一件重要事情是Presentation和Model的划分。在您的模型上做更多的工作，您将看到巨大的好处。
如果您的示例应该有一个Recipe模型，就像Recipe您的DomainModel 一样，并且应该有与配方相关的数据和行为。然后，您将拥有一个RecipeViewModel和 是您的演示文稿的一部分，并拥有Recipe. 然后，你将有你的RecipeView，将被钩住的RecipeViewModel是具有实际的GUI控件代表如何的责任Recipe被提交给用户，并且反应并调整它的小部件/控件的变化RecipeViewModel。
在 MVVM 中，Views通常不与Models. 他们确实与ViewModels那个沟通，然后与Models.
我看到的一个大问题是人们将Models他们存储到数据库中的东西视为应用程序Views，而将其他所有内容（ViewModels、Services等）视为应用程序。这是一个很大的缺陷。如果你还没有读过领域驱动设计，我强烈推荐它，因为它非常详细地解释了拥有好的Models.
以下是一些资源：
https://martinfowler.com/bliki/PresentationDomainDataLayering.html
http://aspiringcraftsman.com/2007/08/25/interactive-application-architecture/