# flutter_mvw

**Repository Path**: flutter-cookbook/flutter_mvw

## Basic Information

- **Project Name**: flutter_mvw
- **Description**: No description available
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2025-11-05
- **Last Updated**: 2025-11-05

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

## 一、MVC

* **Model**：管理数据和业务逻辑。
* **View**：负责界面展示。
* **Controller**：响应用户输入、调用 Model 更新数据、通知 View 刷新。

### ✅ 优点

* **结构简单、开发上手快**（Flutter 默认写法其实就很 MVC）。
* **适合小型项目**，逻辑和界面放在同一个 State 内容易理解。
* **控制器可复用**（理论上）。

### ❌ 缺点

* **Controller 与 View 耦合紧密**，容易变成“胖控制器”。
* **UI 与业务逻辑混在一起**（尤其 Flutter 的 setState 方式），代码难以维护。
* **不利于单元测试**，因为逻辑通常藏在 Widget 内。


---

## 二、MVP

* **Model**：管理数据和业务逻辑。
* **View**：只负责显示（定义接口 `CounterView`）。
* **Presenter**：完全处理逻辑，并通过接口回调更新 View。

### ✅ 优点

* **逻辑与界面彻底分离**：View 不知道数据从哪来，只接收 Presenter 回调。
* **可单独测试 Presenter**，因为它独立于 Flutter Widget。
* **方便多人协作**（UI 和逻辑开发者互不干扰）。

### ❌ 缺点

* **代码样板多**（接口 + 实现 + 绑定逻辑）。
* **View 层仍需手动刷新（回调）**，略显繁琐。
* **Flutter 自身没有天然支持这种分层**（不像 Android 那样有 Activity/View 接口体系）。
* **UI 是声明式的** UI 必须依赖 State 才能 rebuild，View 必须保存状态，所以会出现 _count 这种辅助变量，不像Android MVP 中 View 直接更新 UI，天然不需要 _count 等变量。

---

## ⚙️ 三、MVVM

* **Model**：管理数据和业务逻辑。
* **ViewModel**：负责数据状态与逻辑（可监听的对象，如 `ChangeNotifier`）。
* **View**：监听 ViewModel 的变化，自动刷新 UI。

### ✅ 优点

* **数据驱动 UI，自动刷新**，Flutter 天然支持（`AnimatedBuilder`、`Provider`、`Riverpod`）。
* **解耦彻底**：View 只绑定状态，不处理逻辑。
* **最现代、最推荐的模式**（尤其结合响应式库）。

### ❌ 缺点

* **需要状态管理工具**（`Provider` / `Riverpod` / `Bloc` 等），学习成本略高。
* **调试较困难**（状态流动隐式，可能不容易追踪）。
* **过度抽象时反而复杂**（小项目没必要）。