React本身对软件架构并不特别执着。它是一个库，促进了可重用组件范式以及管理状态和数据共享（props）等事物的指导方针。在某个时候，Facebook将其描述为the V in MVC，但后来不再使用这种营销方式，而是更抽象地称之为A JavaScript library for building user interfaces。
当然，与React应用程序相关的典型工具在一起使用时确实有助于某种架构。
有几种可能的思考方式：

Simple React应用程序可能只是“VVM”或“VC”

在开发领域，MVC可能是这两种模型中比较有名的一种。控制器（C）和视图模型（VM）之间的关键概念差异可以归结为：一个控制器可以有很多不同的职责，比如监听事件并将它们路由到正确的方向。它是促进整个应用程序功能的粘合剂。另一方面，一个视图模型只负责将数据的当前状态粘合到模型上。
因此，Facebook最初使用的“MVC中的V”很可能是“MVVM中的V”--术语控制器在后端开发世界中更有意义。
一个不带Redux的准系统React应用程序可以被称为一个简单的“VVM”模型，它将数据直接拉入组件（例如componentDidMount中的fetch或利用GraphQL），并限制任何类型的数据争论。

视图模型（VM）：与组件相关的代码，用于管理简单状态、将数据直接传递到视图、可能将数据直接从视图传递回来
视图（V）：视觉效果的外观（JSX、CSS）

增加一些复杂性，您可以称之为“MVVM”/“MVC”

如果您使用Redux、redux-saga，甚至使用简单的React组件状态来做一些疯狂的事情，那么您就引入了模型操作。**Model（M）**至少可以表示两件事情：
1.应用程序的实际业务逻辑
1.存储和管理客户端中的复杂行为
业务逻辑在实践中有时是不受欢迎的：例如，如果您可以控制服务器，那么将所有的业务逻辑保存在一个地方（在服务器上）并只向UI提供与用户交互所需的内容可能是值得的。但是，如果您的REST端点有限，并且需要进行一些争论（例如，在您的sagas中，或者在组件中），那么这将是业务逻辑。
客户端行为管理是很有可能的，特别是在复杂的应用程序中，您可能会根据用户的会话向用户显示不同的内容（例如，他们是未注册用户、用户还是管理员）。您可能会在任何redux存储交互中执行此操作，这些交互仅由客户端使用。

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

[1]在answers and comments to this question中讨论了一些更长的长度

Vue 3是MVVM：

Proxy       Update
  Model → ViewModel → View
  Model ← ViewModel ← View
      Update      Event

和React：

setState     Update
  Model → ViewModel → View
  Model ← ViewModel ← View
      Update      Event

不同之处仅在于框架如何将模型更改通知给ViewModel。

一个简单的Web应用程序不需要MVC、MVVM，甚至不需要React IMO。一个简单的ReactJS应用程序的可能演变，如果它试图成为PWA，可能会看到MVVM/MVC的需求（渐进式Web应用程序）。换句话说，如果它尝试做一些（应用程序/域）特定的逻辑-离线和一些其他-在线。这是移动的应用程序开发的自然思维点。然后，信息可以从本地存储或IndexedDB（用于Web）或后端/Rest/中检索。然后，模型、存储/仓库/信息源/视图模型/或控制器/和视图的分离将是自然的，并且实际上需要所有东西正确地工作...