ReactJS 应用程序的 MVVM 架构模式 [英] MVVM architectural pattern for a ReactJS application
问题描述
我是一名半高级 react 和 JavaScript 开发人员，我已经制作了几个通用的 react 应用程序.
I'm a semi-senior react and JavaScript developer, I've made several Universal react application.
今天我们的 CTO 告诉我:您是否为您的应用程序使用软件架构模式?
Today our CTO told me: Do you use a software architectural pattern for your application?
我没有答案，他指的是 Android 团队，他们将 MVVM 用于他们的应用程序.
I've no answer, He points to the Android team which use MVVM for their applications.
我正在搜索，但没有找到适合这种情况的趋势方法或示例.我用过 Redux、Redux-Saga、React-Context 等
I'm searching greedy but not found a trend methodology or example for this situation. I've used Redux, Redux-Saga, React-Context and etc.
我不知道如何向我们的 CTO 解释或他的回答是什么?
I don't know how to explain to our CTO or what is his answer?
因此:react 应用真的需要软件架构模式吗?
Hence: Does a react app really need a software architectural pattern?
推荐答案
React 本身对软件架构并不特别固执.它是一个促进可重用组件范式以及管理状态和数据共享(道具)等内容的指南的库.在某些时候，Facebook 将其描述为 MVC 中的 V，但此后不再采用这种营销方式，而是将其更抽象地称为用于构建用户界面的 JavaScript 库.
React itself is not particularly opinionated about software architecture. It is a library that facilitates the reusable component paradigm alongside guidelines for managing things like state and data sharing (props). At some point, Facebook described this as the V in MVC but have since moved away from that marketing to call it more abstractly A JavaScript library for building user interfaces.
当然，当一起使用时，与 React 应用程序相关的典型工具确实有助于某种架构.
Of course, the typical tooling associated with React apps does lend itself to something of an architecture when used together.
几种可能的思考方式:
MVC 可能是开发界两者中比较知名的.控制器 (C) 和视图模型 (VM) 之间的关键概念差异可以归结为:控制器 可以承担许多不同的职责，例如侦听事件并将它们路由到正确的方向.它是促进整个应用程序功能的粘合剂.另一方面，view-model 只负责将数据的当前状态粘合到模型上.
MVC is probably the better-known of the two in the development world. The key conceptual difference between a controller (C) and view-model (VM) could be boiled down into: a controller can have many diverse responsibilities, like listening for events and routing them in the right direction. It's the glue that facilitates the functionality of an entire application. A view-model, on the other hand, is simply responsible for gluing the current state of the data to the model.
因此，Facebook 最初使用的V in MVC"可能与V in MVVM"一样容易——控制器一词在后端开发领域更有意义.
So Facebook's original use of "V in MVC" could probably just as easily have been "V in MVVM" - the term controller makes more sense in backend development world.
一个没有 Redux 的准系统 React 应用程序，可以将数据直接拉入组件(例如 componentDidMount 中的 fetch 或利用 GraphQL)，并且可以进行任何类型的有限数据处理被称为简单的VVM"模型.
A barebones React app, without Redux, that pulls data directly into components (e.g. fetch's in componentDidMount or leveraging GraphQL) with limited data wrangling of any kind could be called a simple "VVM" model.
View-Model (VM):管理简单状态的组件相关代码，将数据直接传递到 View，可能直接从 View 传回数据
View-Model (VM): Component-related code that manages simple state, passes data directly onto View, potentially passes data directly back from View
视图 (V):视觉效果(JSX、CSS)
View (V): How the visuals look (JSX, CSS)
如果您在 Redux、redux-saga 中折腾，甚至开始用简单的 React 组件状态做一些疯狂的事情，那么您就是在引入模型操作.这个模型 (M) 至少可以代表两件事:
If you toss in Redux, redux-saga, or even start doing crazy things with simple React component state, you're introducing model operations. There're at least two things this Model (M) can represent:
- 应用的实际业务逻辑
- 在客户中存储和管理复杂的行为
业务逻辑在实践中有时是不可取的:例如，如果您可以控制服务器，则可能值得将所有业务逻辑放在一个地方(在服务器上)，并只提供 UI 需要与之交互的内容用户.但是，如果您的 REST 端点有限并且需要进行一些争论(例如在您的传奇中或在组件内)，那就是业务逻辑.
Business logic is sometimes undesirable in practice: for example, if you have control over the server, it might be worth keeping all your business logic in one place (on the server) and just feed the UI what it needs to interact with the user. But if you have limited REST endpoints and need to do some wrangling (e.g. in your sagas, or within components), that'll be business logic.
客户端行为管理是可能的，特别是在复杂的应用程序中，您可能会根据用户的会话向用户显示不同的内容(例如，他们是未注册的用户、用户与管理员).您可能在包含仅供客户端使用的任何 redux 存储交互中执行此操作.
Client behavior management is likely, especially in complex applications where you might be doing things like displaying different things to the user based on their session (e.g. they're an unregistered user vs. user vs. admin). You're probably doing this in any redux store interactions that are contained to use by only the client.
免责声明:讨论 MVC、MVVM 等可能会导致许多不同的意见确切地他们的意思[1].上面，我试图在我所看到的常见模式以及它们如何适应 MVC/MVVM 之间进行比较，但是有很多不同的方法来处理它或更细粒度的方式来思考它.只要您的系统易于理解，我就不会太纠结于给它贴上标签:模块化、DRY、抽象等，级别对您的用例和开发规模有意义.
Disclaimer: discussing MVC, MVVM, etc. is likely to lead to many different opinions of exactly what they mean [1]. Above, I tried to draw parallels between common patterns I've seen and how they fit into MVC/MVVM, but there's so many different ways to approach it or more granular ways to think about it. I wouldn't get too hung up on putting a label on it as long as your system is easy to understand: modular, DRY, abstracted, etc. at levels that make sense for your use case and scale of development.
[1] 在 答案和评论中进行了更详细的讨论这个问题
这篇关于ReactJS 应用程序的 MVVM 架构模式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
