我是一名半高级的React和JavaScript开发者，我曾经制作过多个通用的React应用程序。
今天我们的首席技术官告诉我：你为你的应用程序使用了软件架构模式吗？
我没有答案，他指向了使用MVVM模式的Android团队。
我很贪心地搜索了一番，但没有找到适合这种情况的趋势方法或示例。我已经使用了Redux、Redux-Saga、React-Context等工具。
我不知道如何向我们的首席技术官解释，也不知道他的答案是什么？
因此：一个React应用程序真的需要一个软件架构模式吗？
React本身并没有特别强烈的软件架构观点。它是一个提供可重用组件范例的库，同时提供管理状态和数据共享（props）等指导方针。在某些情况下，Facebook将其描述为“MVC中的V”，但现在已经从该营销概念转向更为抽象的“用于构建用户界面的JavaScript库”。
当然，与React应用程序相关的典型工具会在一起使用时形成某种建筑结构。
有几种可能的思考方式：
MVC可能是开发世界中更为常见的两种方法之一。控制器（C）和视图模型（VM）之间的关键概念差异可以归结为：控制器可以拥有许多不同的职责，例如侦听事件并将其路由到正确的方向。它是促进整个应用程序功能的胶水。另一方面，视图模型仅负责将当前数据状态粘合到模型中。
因此，Facebook最初使用的“MVC中的V”可能很容易变成“MVVM中的V”--术语控制器在后端开发世界中更有意义。
一种没有Redux的简单React应用，可以直接将数据拉入组件中（例如在componentDidMount中使用fetch或利用GraphQL），几乎没有任何数据处理，这种应用可以被称为简单的“VVM”模型。
视图-模型 (VM): 管理简单状态的与组件相关的代码，直接将数据传递到视图，可能会直接从视图返回数据。
视图 (V): 视觉展示 (JSX, CSS)
如果你添加了Redux、redux-saga，甚至开始在简单的React组件状态中进行疯狂操作，那么就引入了模型操作。 这个模型 (M) 至少可以表示以下两点：
实际上，在实践中有时不希望存在业务逻辑：例如，如果您对服务器具有控制权，则值得将所有业务逻辑放在一个地方（即服务器上）并只向UI提供其所需内容以与用户交互。但是，如果您有限的REST端点，需要进行一些加工处理（例如在sagas中或组件内），那么这将是业务逻辑。
客户端行为管理在复杂应用程序中经常出现，特别是当您需要根据用户会话显示不同内容（例如，他们是未注册用户、普通用户还是管理员）时。在仅限于客户端使用的任何redux store交互中，您可能正在执行此操作。
免责声明：讨论MVC、MVVM等往往会导致许多不同的意见来解释它们的确切含义[1]。以上我试图画出我看到的常见模式与它们如何适应MVC/MVVM之间的相似之处，但是有太多不同的方法来处理它或者更细粒度的思考方式来考虑它。只要您的系统易于理解：模块化、DRY、抽象化等，在对您的用例和开发规模有意义的级别上，就不要太纠结于打上一个标签。
[1] 在这个问题的答案和评论中对其进行了更详细的讨论。
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有关Model更改的信息。