Android 中 MVC、MVP 和 MVVM 架构模式的区别

通过应用软件架构模式开发 android 应用程序始终是开发人员的首选。架构模式为项目文件提供了模块化，并确保所有代码都包含在单元测试中。它使开发人员可以轻松地维护软件并在未来扩展应用程序的功能。 MVC(Model-View-Controller)、MVP(Model-View-Presenter)和MVVM(Model-View-ViewModel)是开发者中最流行和业界认可的Android架构模式。

模型—视图—控制器(MVC)模式

MVC 模式建议将代码拆分为 3 个组件。在创建应用程序的类/文件时，开发人员必须将其分类为以下三层之一：

• 模型：此组件存储应用程序数据。它对接口一无所知。该模型负责处理领域逻辑(现实世界的业务规则)以及与数据库和网络层的通信。
• 视图：它是 UI(用户界面)层，其中包含在屏幕上可见的组件。此外，它提供存储在模型中的数据的可视化，并为用户提供交互。
• 控制器：该组件建立视图和模型之间的关系。它包含核心应用程序逻辑并获知用户的响应并根据需要更新模型。

模型—视图—演示者(MVP)模式

MVP 模式克服了 MVC 的挑战，并提供了一种构建项目代码的简单方法。 MVP 被广泛接受的原因是它提供了模块化、可测试性以及更干净和可维护的代码库。它由以下三个部分组成：

• 模型：用于存储数据的层。它负责处理域逻辑(现实世界的业务规则)以及与数据库和网络层的通信。
• 视图： UI(用户界面)层。它提供数据的可视化并跟踪用户的操作以通知演示者。
• Presenter：从模型中获取数据并应用 UI 逻辑来决定要显示的内容。它管理视图的状态并根据用户从视图输入的通知采取行动。

模型 — 视图 — 视图模型 (MVVM) 模式

MVVM 模式与 MVP(Model — View — Presenter) 设计模式有一些相似之处，因为 ViewModel 扮演 Presenter 角色。然而，MVP 模式的弊端已经被 MVVM 解决了。它建议将数据呈现逻辑(视图或 UI)与应用程序的核心业务逻辑部分分开。 MVVM 的独立代码层是：

• Model：这一层负责数据源的抽象。 Model 和 ViewModel 协同工作以获取和保存数据。
• View：这一层的目的是通知 ViewModel 用户的操作。该层观察 ViewModel，不包含任何类型的应用程序逻辑。
• ViewModel：它公开那些与视图相关的数据流。此外，它充当模型和视图之间的链接。

MVC、MVP 和 MVVM 设计模式的区别

MVC(MODEL VIEW CONTROLLER)	MVP(MODEL VIEW PRESENTER)	MVVM(MODEL VIEW VIEWMODEL)
One of the oldest software architecture	Developed as the second iteration of software architecture which is advance from MVC.	Industry-recognized architecture pattern for applications.
UI(View) and data-access mechanism(Model) are tightly coupled.	It resolves the problem of having a dependent View by using Presenter as a communication channel between Model and View.	This architecture pattern is more event-driven as it uses data binding and thus makes easy separation of core business logic from the View.
Controller and View exist with the one-to-many relationship. One Controller can select a different View based upon required operation.	The one-to-one relationship exists between Presenter and View as one Presenter class manages one View at a time.	Multiple View can be mapped with a single ViewModel and thus, the one-to-many relationship exists between View and ViewModel.
The View has no knowledge about the Controller.	The View has references to the Presenter.	The View has references to the ViewModel
Difficult to make changes and modify the app features as the code layers are tightly coupled.	Code layers are loosely coupled and thus it is easy to carry out modifications/changes in the application code.	Easy to make changes in the application. However, if data binding logic is too complex, it will be a little harder to debug the application.
User Inputs are handled by the Controller.	The View is the entry point to the Application	The View takes the input from the user and acts as the entry point of the application.
Ideal for small scale projects only.	Ideal for simple and complex applications.	Not ideal for small scale projects.
Limited support to Unit testing.	Easy to carry out Unit testing but a tight bond of View and Presenter can make it slightly difficult.	Unit testability is highest in this architecture.
This architecture has a high dependency on Android APIs.	It has a low dependency on the Android APIs.	Has low or no dependency on the Android APIs.
It does not follow the modular and single responsibility principle.	Follows modular and single responsibility principle.	Follows modular and single responsibility principle.

想要一个更快节奏和更具竞争力的环境来学习 Android 的基础知识吗?

单击此处前往由我们的专家精心策划的指南，旨在让您立即做好行业准备！