说商店就是模特是正确的吗？

Question

我觉得MVC模式及其派生工具（MVVM，MVP，MVW ..）有点死了。一种新的模式诞生了：状态管理模式（flux，mobx ...）。

好吧，在学习了这些模式之后，它们似乎并没有什么不同，组件是VM，状态是Model，仅此而已。

我是对的吗？

• 如果是，为什么我们需要重命名该实体（用商店代替模型），因此IMO会使理解新概念变得更加复杂，因为我们（我）在寻找一个巨大的差异，该差异确认必须重命名所有内容...
• 如果我错了，请帮助我了解区别在哪里？我的意思是，重命名整个概念肯定有很大的不同...

谢谢

Answer 1

如果您将 DOM 视为View，将 components / VirtualDOM 视为ViewModel，将 store 视为{{1 }}，嗯，它是Model。所以我认为你没错。实际上，在我的项目中，我将全局MobX存储命名为MVVM，并将我的本地MobX存储（适用于某些组件）命名为Store。 （如果有更好的命名方式，请告诉我）

同时，状态管理模式与Model完全不同。

• 模型中的数据：您可以在商店中保存诸如首选语言或主题之类的用户设置，以使您的商店不同于传统的MVVM/MVC/MVW，后者应该处理业务逻辑和数据。
• 模型数量：如果您使用Redux或Hyperapp或类似的东西，则只有一棵全局状态树。因此，它与创建许多Model对象的传统方式完全不同。
• 组件驱动：您不需要处理所有事情。您可以仅导入由其他人创建的组件，然后简单地将数据传递给它。然后它将处理用户交互并自行更新视图。也许包含Model，也许包含Controller，也许都不包含。没关系你根本不在乎。
• 快照：您可以拍摄状态快照，并将其另存为字符串。下次您可以解析字符串并恢复所有网站/系统。就像保存/加载电子游戏一样。这是状态管理模式的原理。尽管传统的Model方法不会强迫您这样做。 （而且我认为传统方式很难做到这一点，也许是不可能的）
• 不可变：以R​​eact为例，您有一个状态和一个虚拟dom树，您不对其进行更改，而是生成一个新的状态和新的树来替换旧的树。您应该了解树的生命周期，并知道如何有效地生成新树。显然，它与传统的MVVM/MVW方法不同。

因此，我认为以新的方式命名诸如组件或商店之类的实体并不是一个坏主意。如果您以旧的方式命名它们，也许程序员会以旧的方式进行编码，结果他们将无法享受现代框架的全部功能。