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

Question

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

今天，我们的CTO告诉我:您在应用程序中使用了软件架构模式吗？

我没有答案，他指出Android团队在他们的应用程序中使用MVVM。

我正在寻找贪婪，但没有找到一个趋势，方法或例子为这种情况。我用过Redux，Redux-Saga，React-Context等。

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

因此：应用程序真的需要软件体系结构模式吗？

Answer 1

React本身对软件体系结构并不是特别固执己见。它是一个库，它为可重用组件范例提供了便利，同时也为管理诸如状态和数据共享(props)之类的事情提供了指导方针。在某种程度上，Facebook将其描述为the V in MVC，但自那以后，它已经脱离了市场营销，更抽象地称它为A JavaScript library for building user interfaces。

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

有几种潜在的思考方法：

简单的反应应用程序可能只是"VVM“或"VC”。

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

因此，Facebook最初使用的“MVC中的V”可能也很容易成为“MVVM中的V”--在后端开发世界中，控制器这个词更有意义。

一个没有Redux的简单反应应用程序直接将数据拉到组件中(例如，fetch在componentDidMount中或利用GraphQL)，而任何类型的有限数据冲突都可以被称为简单的"VVM“模型。

视图-模型(VM)：管理简单状态的与组件相关的代码，直接将数据传递给视图，潜在地从视图直接传递数据

视图(V)：视觉效果如何(JSX，CSS)

增加一些复杂性，您可以将其称为"MVVM"/"MVC“

如果您加入了Redux、redux-saga，或者甚至开始使用简单的React状态做疯狂的事情，那么您就是在引入模型操作。这个模型(M)至少可以表示两件事情：

1. 应用程序的实际业务逻辑
2. 在客户端中存储和管理复杂行为

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

客户端行为管理是可能的，特别是在复杂的应用程序中，您可能会根据用户会话向用户显示不同的内容(例如，他们是未注册的用户，而不是用户和管理员)。您可能会在仅由客户端使用的任何redux存储交互中执行此操作。

免责声明：讨论MVC、MVVM等可能会导致对它们的确切含义有许多不同的看法。在上面，我试图将我看到的常见模式与它们如何融入MVC/MVVM之间进行比较，但是有很多不同的方法来处理它，或者更细粒度的方式来思考它。只要您的系统易于理解:模块化、枯燥、抽象等对于您的用例和开发规模都有意义，我就不会太在意在它上贴标签。

1在answers and comments to this question中更长的部分中讨论

Answer 2

Vue 3是MVVM：

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

并作出反应：

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

区别仅在于框架如何通知模型更改到ViewModel。

Answer 3

一个简单的Web应用程序不需要MVC，MVVM，甚至不需要对IMO做出反应。一个简单的ReactJS应用程序的可能发展，它可能会看到MVVM/MVC的需要/如果它试图成为PWA (渐进的Web )。换句话说，如果它试图做一些(应用程序/域)特定的逻辑离线和其他一些在线。这是移动应用程序开发的自然思维点。然后，可以从本地存储或IndexedDB (用于网络)或后端/Rest/检索信息。然后，分离的模型，存储/存储/信息源/查看模型/或控制器/和视图将是自然的，所有的东西实际需要正确工作。