Javascript ReactJS应用程序的MVVM体系结构模式

我是一名半高级

react

和

JavaScript

开发人员，我开发了几个通用

react

应用程序

今天，我们的CTO告诉我：您的应用程序是否使用软件体系结构模式

我没有答案，他指的是

Android

团队，他们在应用程序中使用

MVVM

我正在搜索贪婪，但没有找到这种情况的趋势方法或示例。我用过

Redux

，

Redux传奇

，

React Context

等等

我不知道如何向我们的CTO解释，或者他的答案是什么

---

因此：一个

react

应用程序真的需要一个软件架构模式吗？

react本身对软件架构不是特别固执己见。它是一个库，促进了可重用组件范例以及管理状态和数据共享（props）等事项的指南。在某种程度上，Facebook将其描述为MVC中的V，但后来从市场营销中移开，将其更抽象地称为用于构建用户界面的JavaScript库

当然，与React应用程序相关联的典型工具在一起使用时确实适合某种体系结构

有几种可能的思考方法：

简单的React应用程序可能只是“VVM”或“VC” MVC可能是开发界更为人所知的两种模式之一。控制器（C）和视图模型（VM）在概念上的主要区别可以归结为：控制器可以承担许多不同的职责，比如侦听事件并将其发送到正确的方向。它是促进整个应用程序功能的粘合剂。另一方面，视图模型只负责将数据的当前状态粘贴到模型

所以Facebook最初使用的“MVC中的V”很可能就是“MVVM中的V”——控制器这个术语在后端开发领域更有意义

一个没有Redux的裸体React应用程序可以将数据直接拉入组件（例如

componentDidMount

中的

fetch

，或利用GraphQL），并具有任何类型的有限数据争用，可以称为简单的“VVM”模型

视图模型（VM）：与组件相关的代码，用于管理简单状态，将数据直接传递到视图，可能直接从视图返回数据

视图（V）：视觉效果如何（JSX、CSS）

增加一些复杂性，您可以称之为“MVVM”/“MVC” 如果您投入Redux，

Redux传奇

，甚至开始用简单的React组件状态做疯狂的事情，那么您就是在引入模型操作。这个模型（M）至少可以代表两个方面：

应用程序的实际业务逻辑

在客户机中存储和管理复杂行为

业务逻辑在实践中有时是不受欢迎的：例如，如果您可以控制服务器，那么将所有业务逻辑保留在一个位置（服务器上）并向UI提供与用户交互所需的信息可能是值得的。但是，如果您的REST端点有限，并且需要进行一些争论（例如，在您的传奇中，或者在组件中），那么这就是业务逻辑

客户机行为管理是可能的，特别是在复杂的应用程序中，您可能会根据用户的会话向用户显示不同的内容（例如，他们是未注册用户vs.用户vs.管理员）。您可能在任何只包含供客户端使用的redux存储交互中执行此操作

---

免责声明：讨论MVC、MVVM等可能会导致对它们的确切含义产生许多不同的意见[1]。在上面，我试图在我所看到的常见模式和它们如何适合MVC/MVVM之间画出相似之处，但是有很多不同的方法来处理它，或者更精细的方法来思考它。只要您的系统易于理解，我就不会太在意在它上面贴标签：模块化的、干燥的、抽象的，等等，这些级别对于您的用例和开发规模是有意义的

---

[1] 一个简单的Web应用不需要MVC，MVVM，甚至不需要React IMO。

---

一个简单的ReactJS应用程序的可能演变，如果它试图成为PWA（渐进式Web应用程序），可能会看到MVVM/MVC/的需要。换句话说，如果它尝试离线执行某些（应用程序/域）特定的逻辑，而尝试在线执行其他逻辑。这是移动应用程序开发的自然思路。然后，可以从本地存储器或IndexedDB（用于Web）或后端/Rest/检索信息。然后，模型、存储/存储库/信息源/视图模型/或控制器/视图的分离将是很自然的，而且所有东西都需要这样才能正常工作……

我喜欢你回答的这一部分：一个没有Redux的裸体React应用程序，它直接将数据拉入组件（例如，在componentDidMount中获取数据或利用GraphQL）任何类型的有限数据争论都可以称为简单的“VVM”模型。React组件可以看作是ViewController：