我是一个半高级的react和JavaScript开发人员，我已经开发了几个通用的react应用程序。

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

"我没有答案，"他指向使用MVVM作为他们应用程序的Android团队。

我在搜索贪婪，但没有找到这种情况的趋势方法或例子。我用过Redux、Redux-Saga、React-Context等。

我不知道如何向我们的首席技术官解释，或者他的答案是什么？

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

React本身对软件架构没有特别的看法。它是一个库，有助于实现可重用的组件范式，以及管理状态和数据共享(props)等内容的指导原则。在某种程度上，Facebook将其描述为the V in MVC，但从那时起，Facebook就不再使用这种营销方式，更抽象地称之为A JavaScript library for building user interfaces。

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

一些可能的思考方法：

MVC可能是开发世界中两个比较有名的公司。控制器(C)和视图模型(VM)之间的关键概念差异可以归结为：控制器可以有许多不同的职责，比如监听事件并将它们按正确的方向路由。它是促进整个应用程序功能的胶水。另一方面，视图模型只负责将数据的当前状态粘贴到模型中。

因此，Facebook最初使用的"v in MVC"可能和"v in MVVM"一样简单——在后端开发领域，术语controller更有意义。

一个没有Redux的准系统反应应用程序，它直接将数据拉入组件(例如，componentDidMount中的fetch或利用graphql)，并限制任何类型的数据争论，可以称为一个简单的"vvm"模型。

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

视图(V)：视觉效果(JSX、CSS)

如果您使用redux、redux-saga，或者甚至开始使用简单的react组件状态做疯狂的事情，那么您将引入模型操作。这个模型(m)至少可以表示两种情况：

业务逻辑在实践中有时是不可取的：例如，如果您对服务器有控制权，那么将所有业务逻辑放在一个地方(在服务器上)可能是值得的，并且只需向UI提供与用户交互所需的内容。但是，如果您有有限的REST端点，并且需要进行一些争论(例如，在您的传奇中，或者在组件中)，那么这就是业务逻辑。

客户机行为管理很有可能，特别是在复杂的应用程序中，您可能会执行一些操作，例如根据用户会话向用户显示不同的内容(例如，他们是未注册的用户，而不是用户与管理员)。您可能在任何ReduxStore交互中都会这样做，这些交互仅由客户机使用。

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

[1]在回答和评论中更详细地讨论了这个问题。