MVC

MVC 模式代表 Model-View-Controller（模型-视图-控制器） 模式。这种模式用于应用程序的分层开发。

MVC 模式 | 菜鸟教程

• Module（模型）：模型代表一个存取数据的对象或 JAVA POJO。它也可以带有逻辑，在数据变化时更新控制器。

• View（视图）：视图表示可视化界面，也就是用户可以直接看到的界面。（例如：网页、手机App界面）

• Controller（控制器）：控制器作用于模型与视图之间，是其沟通的桥梁。它控制着数据流向模型，并在数据变化时更新视图。使视图与模型分离不耦合

主要解决问题

• 解决了应用程序中业务逻辑、数据和界面显示的耦合问题，使得开发和维护更加清晰和简单。

使用场景

• 当需要将数据、业务逻辑和界面显示分离，以便于独立开发和维护时。

实现方式

• 模型（Model）：负责数据和业务逻辑，通常包含数据存储、检索和业务规则。

• 视图（View）：负责显示数据（模型）的用户界面，不包含业务逻辑。

• 控制器（Controller）：接收用户的输入，调用模型和视图去完成用户的请求。

关键代码

• 模型：包含业务逻辑和数据状态。

• 视图：包含展示逻辑，将模型的数据渲染为用户界面。

• 控制器：包含逻辑，用于响应用户输入并更新模型和视图。

应用实例

• Web应用程序：用户通过浏览器（视图）发送请求，服务器端的控制器处理请求，模型进行数据处理。

优点

• 关注点分离：将数据、业务逻辑和界面显示分离，降低耦合度。

• 易于维护：每个组件负责特定的任务，便于单独开发和维护。

• 可扩展性：可以独立地替换或更新模型、视图或控制器。

缺点

• 可能增加复杂性：对于简单项目，引入MVC可能会增加不必要的复杂性。

• 性能问题：如果不正确使用，可能会导致性能问题。

使用建议

• 当开发大型应用程序，需要清晰分离数据、业务逻辑和用户界面时，考虑使用MVC模式。

注意事项

• 确保模型、视图和控制器之间的交互清晰，避免相互依赖。

MVP

MVCP模式代表 Model-View-Presenter（模型-视图-演示器） 模式。这种模式用于应用程序的分层开发。

• Module（模型）：模型代表一个存取数据的对象或 JAVA POJO。它也可以带有逻辑，在数据变化时更新控制器。

• View（视图）：视图表示可视化界面，也就是用户可以直接看到的界面。（例如：网页、手机App界面）

• Presenter（演示器）：充当 View 和 Model 之间的协调者。接收 View 的请求，调用 Model 处理数据，根据结果格式化数据，并指示 View 进行更新。

主要解决问题

• MVP 的核心在于 View 和 Presenter 通过接口进行双向通信，实现了 View 和业务逻辑的完全隔离。

使用场景

• 核心场景：MVP 最适合「中小型移动端项目、新手团队、老项目渐进式重构」，平衡了解耦性和开发效率；

实现方式

• 模型（Model）：负责数据和业务逻辑，通常包含数据存储、检索和业务规则。

• 视图（View）：负责显示数据（模型）的用户界面，不包含业务逻辑。

• 演示器（Presenter）：对于Presenter层他是连接View层与Model层的桥梁并对业务逻辑进行处理。在MVP架构中Model与View无法直接进行交互。所以在Presenter层它会从Model层获得所需要的数据，进行一些适当的处理后交由View层进行显示。这样通过Presenter将View与Model进行隔离，使得View和Model之间不存在耦合，同时也将业务逻辑从View中抽离。

关键代码

• 模型：包含业务逻辑和数据状态。

• 视图：包含展示逻辑，将模型的数据渲染为用户界面。

• 演示器：包含逻辑，用于响应用户输入并更新模型和视图。

应用实例

• 中小型项目、新手团队：该实模式完美适配代码无复杂语法（纯 Java）、模板代码少、逻辑清晰，开发效率高；

优点

• 彻底解耦：View（界面）、ViewModel（逻辑）、Model（数据）完全分离：改 UI 不用动逻辑，改逻辑不用动 UI；

• 易于维护：每个组件负责特定的任务，便于单独开发和维护。

• 可测试性大幅提升：Presenter 是纯 Java/Kotlin 类，依赖的是 View 接口（而非具体 Activity），可 Mock View 接口做单元测试；无需真机 / 模拟器，直接在 JVM 环境测试核心业务逻辑。

• 代码复用性更高：Presenter 中的业务逻辑可复用（如多个页面的登录逻辑）；View 接口可适配不同实现（如 Activity/Fragment/Dialog 共用一个 Presenter）。

• 新手易理解：核心是「接口 + 回调」，无需学习响应式编程（如 Flow/LiveData）、生命周期管理（如 ViewModel）；纯 Java 即可落地，适配传统安卓开发团队。

缺点

• 模板代码极度冗余：每个页面需写「View 接口 + Presenter 接口 + Presenter 实现 + 契约类」，页面越多代码量越膨胀；简单功能（如单个按钮点击）也需写全套接口，开发效率低。

• 内存泄漏风险（隐性）：Presenter 持有 View 接口引用，若忘记在 onDestroy 调用 detachView()，会导致 Activity 无法被回收； 子线程异步请求未取消时，Presenter 持有的 View 引用仍会泄漏。

• 生命周期适配差：Presenter 无自带的生命周期管理，需手动处理「Activity 暂停 / 恢复」时的逻辑；横竖屏重建时，Presenter 需重新绑定 View，易出现数据不一致。

• 不适配响应式 UI:MVP 基于「接口回调」，与 Compose/Flutter 等「状态驱动 UI」思想冲突；用 MVP 开发 Compose 页面，会出现「回调嵌套 + 状态手动同步」的冗余代码。

使用建议

• 小项目 / 工具类 App、中小型项目 / 外包项目、老项目 MVC 重构、新手团队 / 传统 Java 团队

注意事项

• 新手最容易陷入「过度设计」，先掌握核心三层结构，不用一上来就加各种复杂组件。

MVVM

MVC 模式代表 Model-View-ViewModel（模型-视图-视图模型） 模式。在 MVVM这种模式 中，数据绑定和命令模式是核心机制，它可以让 View 与 ViewModel 同步更新，而无需手动编写繁琐的代码。

• Module（模型）：模型层，负责管理应用的业务逻辑和数据。它是与服务器通信的核心，也是数据处理的地方。Model 完全不关心 UI 如何展示。

• View（视图）：视图层，直接与用户交互的界面，View 的职责是展示 Model 中的数据。View 只关注如何显示数据，不处理逻辑。

• ViewModel（视图模型）：视图模型层，作为 View 与 Model 之间的桥梁。它包含了 UI 逻辑，但不直接操作 UI，而是通过数据绑定来驱动 View 的变化。ViewModel 提供数据给 View，并且将用户的输入处理传递给 Model。

主要解决问题

• 解决了应用程序中业务逻辑、数据和界面显示的耦合问题，使得开发和维护更加清晰和简单。

使用场景

• 当需要将数据、业务逻辑和界面显示分离，以便于独立开发和维护时。

实现方式

• 模型（Model）：负责数据和业务逻辑，通常包含数据存储、检索和业务规则。

• 视图（View）：负责显示数据（模型）的用户界面，不包含业务逻辑。

• 视图模型（ViewModel）：连接视图和模型的桥梁，负责从模型中获取数据，并将其转换为视图可以使用的格式，同时也负责将视图中的用户交互事件转换为模型可以理解的操作。视图模型中不包含任何与视图相关的代码，从而实现了解耦。

关键代码

• 模型：包含业务逻辑和数据状态。

• 视图：包含展示逻辑，将模型的数据渲染为用户界面。

• 视图模型：只聚焦数据处理和业务逻辑，完全不包含任何与 UI 相关的代码（如 findViewById、setText 等），其代码结构遵循「数据持有 + 逻辑处理 + 生命周期兼容」三大原则

应用实例

• App应用程序

优点

• 彻底解耦：View（界面）、ViewModel（逻辑）、Model（数据）完全分离：改 UI 不用动逻辑，改逻辑不用动 UI；

• 易于维护：每个组件负责特定的任务，便于单独开发和维护。

• 可测试性极高：ViewModel 是纯 Kotlin/Java 类，无 UI 依赖：单元测试可在 JVM 环境跑（无需真机 / 模拟器）；可 Mock Model 数据，覆盖所有业务场景（如网络错误、数据为空）；测试覆盖率提升，减少线上 Bug。

• 减少 UI 胶水代码：数据绑定（如 LiveData/StateFlow + Compose）自动同步 UI，无需手动写 setText()``setVisibility()：代码量减少 30%+；避免异步更新 UI 导致的空指针 / 内存泄漏。

• 生命周期安全：ViewModel 由系统托管，独立于 Activity/Fragment 生命周期：横竖屏重建、后台切前台时数据不丢失；viewModelScope 自动取消异步任务，避免内存泄漏。

缺点

• 学习成本高：需掌握：数据绑定（LiveData/StateFlow/Flow）；协程 / RXJava（异步处理）；ViewModel 生命周期；Compose 状态管理（进阶）。

• 简单项目过度设计：小项目（如工具类 App、单页面 Demo）用 MVVM 会增加模板代码（ViewModel/Repository/Flow 等），开发效率低。

• 数据绑定调试难：自动数据同步导致「数据从哪来、到哪去」不直观：调试时难定位 UI 更新的源头；双向绑定（如输入框）易出现数据循环更新。

• 内存泄漏风险（隐性）：若不小心在 ViewModel 中持有 Activity/Fragment 引用（如传了非 Application Context），会导致比 MVC 更隐蔽的内存泄漏。

使用建议

• 核心原则：MVVM 落地的关键是「守边界」—— View 只管展示，ViewModel 只管逻辑，Model 只管数据，绝不跨层做事；

• 落地节奏：从小到大，先搭最小结构跑通，再逐步加入 Repository、Hilt、UseCase 等优化；

• 避坑核心：杜绝 ViewModel 持有 View 引用、避免过度设计、做好异常处理和单元测试；

• 工程价值：MVVM 不是「炫技」，而是为了大型项目的可维护性、可测试性，这也是 T9 架构师的核心能力要求。

注意事项

• 新手最容易陷入「过度设计」，先掌握核心三层结构，不用一上来就加各种复杂组件。