Android中的MVC，MVP和MVVM架构模式之间的差异

通过应用软件架构模式开发android应用程序始终是开发人员的首选。架构模式为项目文件提供了模块化，并确保所有代码都包含在单元测试中。它使开发人员将来可以轻松完成维护软件和扩展应用程序功能的任务。 MVC(模型-视图-控制器)，MVP(模型-视图-演示者)和MVVM(模型-视图-演示者)是开发人员中最受欢迎和业界认可的android体系结构模式。

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

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

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

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

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

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

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

MVVM模式与MVP(模型—视图—演示者)设计模式有一些相似之处，因为演示者角色是由ViewModel扮演的。但是，MVVM解决了MVP模式的缺点。它建议将数据表示逻辑(视图或UI)与应用程序的核心业务逻辑部分分开。 MVVM的单独代码层是：

• 模型：该层负责数据源的抽象。 Model和ViewModel一起工作以获取和保存数据。
• 视图：该层的目的是向ViewModel通知用户的操作。该层遵守ViewModel，不包含任何类型的应用程序逻辑。
• ViewModel：它公开了与View相关的那些数据流。而且，它作为模型与视图之间的链接而充当服务器。

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的基础知识吗?

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