我是一名react级和JavaScript级的半高级开发人员，我已经开发了几个Universal react应用程序.
今天我们的首席技术官告诉我:Do you use a software architectural pattern for your application?
我没有答案，他指的是Android个团队，他们的应用程序使用MVVM.
我正在搜索贪婪，但没有找到这种情况的趋势方法或示例.我用了Redux、Redux-Saga、React-Context等等.
我不知道如何向我们的首席技术官解释，或者他的答案是什么？
因此:Does a 100 app really need a software architectural pattern?
React本身对软件架构并不是特别固执己见.它是一个促进可重用组件范例以及管理状态和数据共享(props)等内容的指南的库.在某种程度上，Facebook将其描述为the V in MVC，但此后，它从市场营销转移到了更抽象的A JavaScript library for building user interfaces.
当然，与React应用程序相关的典型工具在一起使用时确实适合某种体系 struct .
有几种可能的思考方法:
MVC可能是开发界更知名的两个.控制器(C)和视图模型(VM)在概念上的关键区别可以归结为:controller可以有许多不同的职责，比如监听事件并将它们发送到正确的方向.它是促进整个应用程序功能的粘合剂.另一方面，view-model只负责将数据的当前状态粘贴到模型上.
所以Facebook最初使用的"MVC中的V"可能也很容易被称为"MVVM中的V"——控制器这个术语在后端开发领域更有意义.
一个没有Redux的barebones React应用程序可以将数据直接拉入组件(例如componentDidMount中的fetch或利用GraphQL)，并进行任何类型的有限数据争论，可以称之为简单的"VVM"模型.
View-Model (VM):与组件相关的代码，用于管理简单的状态，将数据直接传递到视图，可能直接从视图返回数据
View (V):视觉效果如何(JSX、CSS)
如果你加入Redux，redux-saga，甚至开始用简单的React组件状态做一些疯狂的事情，你就是在引入模型操作.这个Model (M)至少可以代表两件事:
业务逻辑在实践中有时是不受欢迎的:例如，如果您可以控制服务器，那么将所有业务逻辑保留在一个位置(服务器上)并向UI提供与用户交互所需的信息可能是值得的.但是，如果您的REST端点有限，并且需要进行一些争论(例如，在您的传奇中，或者在组件中)，那么这就是业务逻辑.
客户端行为管理很有可能，尤其是在复杂的应用程序中，您可能会根据用户的会话向用户显示不同的内容(例如，他们是未注册用户，而不是用户，而不是管理员).您可能在任何只供客户机使用的reduxstore 交互中进行了此操作.
Disclaimer:讨论MVC、MVVM等可能会导致人们对其含义产生许多不同的看法[1].在上面，我试图在我所看到的常见模式和它们如何融入MVC/MVVM之间画出相似之处，但有很多不同的方法来处理它，或者更精细的方式来思考它.只要你的系统易于理解，我就不会太在意给它贴上标签:模块化的、干燥的、抽象的，等等，在对你的用例和开发规模有意义的层次上.
[1] 在第二章中讨论，在第answers and comments to this question章中有更长的篇幅