说到前端的三大主流框架大家都知道，react，vue，angular等，过去还有古老的jsp，juqery等等，前端跟随时代一直在发展，那么我们一起来总结一下MVVM，MVP，MVC，Flux，Redux，MobX等前端的常见架构模式，以及使用场景。
MVVM（Model-View-ViewModel）：
- 模型（Model）：表示数据和业务逻辑。
- 视图（View）：表示用户界面，通常是由 HTML、CSS 和 DOM 元素组成。
- 视图模型（ViewModel）：连接视图和模型的中间层，负责处理视图的逻辑和数据绑定。ViewModel 通常是一个纯粹的 JavaScript 对象，包含了视图需要展示的数据和方法。
MVVM 的核心思想是数据驱动视图，通过数据绑定机制实现视图和模型之间的自动同步。当模型发生变化时，视图会自动更新；当用户在视图中进行操作时，视图模型会自动更新模型。
在前端框架中，比较典型的 MVVM 框架是 Vue.js，Vue.js 提供了响应式数据绑定和指令等功能，使得开发者可以轻松地构建 MVVM 架构的应用。
MVP（Model-View-Presenter）：
- 模型（Model）：表示数据和业务逻辑。
- 视图（View）：表示用户界面，通常是由 HTML、CSS 和 DOM 元素组成。
- 主持人（Presenter）：连接视图和模型的中间层，负责处理视图的逻辑和模型的交互。Presenter 通常是一个 JavaScript 对象，包含了视图的事件处理逻辑和模型的操作方法。
MVP 的核心思想是解耦视图和模型，通过主持人来协调视图和模型之间的交互。视图不直接操作模型，而是通过主持人来间接操作，从而实现了视图和模型的解耦。
在 MVP 架构中，视图是 passively 表示用户界面，主持人负责更新视图的状态和处理用户操作，模型则负责数据的存储和业务逻辑的处理。MVP 架构适用于对 UI 控制和逻辑分层更为严格的应用场景。
区别总结：
- MVVM 更加强调数据驱动视图，通过数据绑定实现视图和模型之间的自动同步，更适用于数据驱动型的应用场景。
- MVP 更加强调解耦视图和模型，通过主持人来协调视图和模型之间的交互，更适用于 UI 控制和逻辑分层更为严格的应用场景。
综上所述，MVVM 和 MVP 是两种不同的前端架构模式，每种模式都有其独特的优点和适用场景。开发者可以根据项目需求和特点选择合适的架构模式。
除了 MVVM 和 MVP，还有一种常见的前端架构模式是 MVC（Model-View-Controller）。
MVC（Model-View-Controller）：
- 模型（Model）：表示数据和业务逻辑。
- 视图（View）：表示用户界面，通常是由 HTML、CSS 和 DOM 元素组成。
- 控制器（Controller）：连接视图和模型的中间层，负责处理用户的输入和业务逻辑。控制器接收用户的输入并根据业务逻辑更新模型和视图。
MVC 的核心思想是将应用程序分成三个部分：模型、视图和控制器，其中模型负责处理数据和业务逻辑，视图负责显示用户界面，控制器负责处理用户的输入和更新模型和视图。MVC 架构使得应用程序的各个部分之间相互解耦，便于管理和维护。
在前端开发中，MVC 架构常用于传统的后端渲染应用，例如使用服务器端模板引擎生成 HTML 页面的应用。控制器通常由后端服务端框架负责处理，而模型和视图则由前端负责处理。
除了MVVM、MVP和MVC之外，还有一些其他的前端架构模式，例如：
Flux：
Flux 是一种单向数据流的架构模式，由 Facebook 提出。它将应用程序分成四个部分：Action、Dispatcher、Store 和 View。其中，Action 表示用户的操作，Dispatcher 负责分发 Action，Store 存储应用程序的状态，View 表示用户界面。Flux 架构的核心思想是通过单向数据流来管理应用程序的状态，使得应用程序的状态变化可预测且易于调试。
Redux：
Redux 是基于 Flux 架构的状态管理库，由 Dan Abramov 和 Andrew Clark 开发。它采用单一的不可变数据源来管理整个应用的状态，通过纯函数来处理状态的变化。Redux 的核心概念包括 Action、Reducer 和 Store，其中 Action 表示用户的操作，Reducer 用于更新应用程序的状态，Store 用于存储应用程序的状态。Redux 提供了强大的开发工具和中间件，使得状态管理变得简单和可预测。
MobX：
MobX 是另一种状态管理库，它采用响应式编程的思想来管理应用程序的状态。MobX 可以将任何可观察的 JavaScript 对象转换成响应式对象，当响应式对象发生变化时，会自动更新依赖于它的组件。MobX 的核心概念包括 Observable、Action 和 Computed，其中 Observable 表示可观察的对象，Action 用于修改状态，Computed 用于计算状态的派生值。
微前端（Micro Frontends）：
微前端是一种将前端应用程序分解成独立的、可独立部署和维护的小型应用的架构模式。每个微前端都拥有独立的技术栈和团队，通过统一的容器来组合和展示这些微前端应用。微前端架构使得前端应用程序更加灵活和可扩展，便于团队协作和应用程序的管理和维护。
以上是一些常见的前端架构模式，每种模式都有其独特的优点和适用场景，开发者可以根据项目需求和特点选择合适的架构模式。
除了上述提到的前端架构模式外，还有一些其他的架构模式，包括但不限于：
CQRS（Command Query Responsibility Segregation）：
CQRS 是一种将应用程序的读操作（Query）和写操作（Command）分离的架构模式。它将应用程序的读模型（Query Model）和写模型（Command Model）分别设计为两个独立的模型，从而实现了读写分离。CQRS 架构模式适用于复杂的应用程序，能够更好地满足不同类型的查询和更新需求，提高应用程序的性能和可维护性。
Event Sourcing：
Event Sourcing 是一种将应用程序的状态和行为都表示为事件序列的架构模式。它将应用程序的状态表示为一系列不可变的事件，每个事件都包含了应用程序在某个时间点发生的状态变化。通过事件的序列化和持久化，可以实现应用程序的状态恢复和历史回溯。Event Sourcing 架构模式适用于需要记录和追溯应用程序状态变化的场景，例如金融交易系统和日志记录系统等。
最后也是全文最重要的，码字不易，你的鼓励是我持之以恒的动力，欢迎关注点赞搜藏，我会定时输送全栈技术干货！！！