说store就是模型对不对？
Is it right to say that store is the model?
我觉得 MVC 模式及其衍生物（MVVM、MVP、MVW..）有点死了。一种新模式诞生：状态管理模式（flux、mobx...）。
嗯，学了这些模式，好像区别不大，component就是VM，state就是Model就是了。
我说的对吗？
- 如果是，为什么我们需要重命名该实体（存储而不是模型），IMO 使理解新概念变得更加复杂，因为我们（我）搜索了一个很大的差异，它确认一切都必须重命名...
- 如果我说错了，请帮我看看哪里不一样？我的意思是重命名整个概念肯定有很大的不同......
谢谢
如果您将 DOM 视为 View，components/VirtualDOM 则视为 ViewModel, 将 存储为 Model，好吧，我认为它是 MVVM。所以我认为你没有错。实际上，在我的项目中，我将我的全局 MobX 存储命名为 Store，并将我的本地 MobX 存储（为某些组件工作）命名为 Model。 （如果有更好的命名习惯请告诉我）
同时，状态管理模式与MVVM/MVC/MVW有很大不同。
- 模型中的数据：您可以在商店中保存用户设置，例如首选语言或主题，这样您的商店就不同于传统的
Model，这应该是处理业务逻辑和数据。
- 模型数量：如果你使用 Redux 或 Hyperapp 之类的，只有一个全局状态树。因此，它与创建大量
Model 个对象的传统方式完全不同。
- Component-Driven：您不需要处理所有事情。您可以只导入一个由其他人创建的组件，然后简单地将数据传递给它。然后它将处理用户交互并自行更新视图。也许它包含一个
Controller，也许它包含一个Model，也许它包含其中的none。没关系。你根本不在乎。
- Snapshot：您可以拍摄状态快照并将其保存为字符串。下次你可以只解析字符串并恢复所有 website/system。就像电子游戏的save/load一样。这是状态管理模式的一个原则。虽然传统的
MVVM/MVW 方式不会强迫您这样做。 （而且我认为传统方法很难做到这一点，也许是不可能的）
- Immutable：以React为例，你有一个state和一个virtual-dom树，你不改变它们，你生成一个新的state和一个新树取代旧树。您应该了解树的生命周期，并知道如何有效地生成新树。明显不同于传统的
MVVM/MVW方式。
所以我认为以新的方式命名组件或商店等实体并不是一个坏主意。如果你用旧的方式命名它们，也许程序员会用旧的方式编码，结果他们将无法享受现代框架的全部功能。
我觉得 MVC 模式及其衍生物（MVVM、MVP、MVW..）有点死了。一种新模式诞生：状态管理模式（flux、mobx...）。
嗯，学了这些模式，好像区别不大，component就是VM，state就是Model就是了。
我说的对吗？
- 如果是，为什么我们需要重命名该实体（存储而不是模型），IMO 使理解新概念变得更加复杂，因为我们（我）搜索了一个很大的差异，它确认一切都必须重命名...
- 如果我说错了，请帮我看看哪里不一样？我的意思是重命名整个概念肯定有很大的不同......
谢谢
如果您将 DOM 视为 View，components/VirtualDOM 则视为 ViewModel, 将 存储为 Model，好吧，我认为它是 MVVM。所以我认为你没有错。实际上，在我的项目中，我将我的全局 MobX 存储命名为 Store，并将我的本地 MobX 存储（为某些组件工作）命名为 Model。 （如果有更好的命名习惯请告诉我）
同时，状态管理模式与MVVM/MVC/MVW有很大不同。
- 模型中的数据：您可以在商店中保存用户设置，例如首选语言或主题，这样您的商店就不同于传统的
Model，这应该是处理业务逻辑和数据。 - 模型数量：如果你使用 Redux 或 Hyperapp 之类的，只有一个全局状态树。因此，它与创建大量
Model个对象的传统方式完全不同。 - Component-Driven：您不需要处理所有事情。您可以只导入一个由其他人创建的组件，然后简单地将数据传递给它。然后它将处理用户交互并自行更新视图。也许它包含一个
Controller，也许它包含一个Model，也许它包含其中的none。没关系。你根本不在乎。 - Snapshot：您可以拍摄状态快照并将其保存为字符串。下次你可以只解析字符串并恢复所有 website/system。就像电子游戏的save/load一样。这是状态管理模式的一个原则。虽然传统的
MVVM/MVW方式不会强迫您这样做。 （而且我认为传统方法很难做到这一点，也许是不可能的） - Immutable：以React为例，你有一个state和一个virtual-dom树，你不改变它们，你生成一个新的state和一个新树取代旧树。您应该了解树的生命周期，并知道如何有效地生成新树。明显不同于传统的
MVVM/MVW方式。
所以我认为以新的方式命名组件或商店等实体并不是一个坏主意。如果你用旧的方式命名它们，也许程序员会用旧的方式编码，结果他们将无法享受现代框架的全部功能。