Android安卓架构MVC、MVP、MVVM模式的概念与区别

目次
MVC框架
MVP框架
MVVM框架
MVVM与MVP区别
MVVM与MVC区别
MVC、MVP、MVVM模式哪个要好一些

---

MVC（Model-View-Controller）、MVP（Model-View-Presenter）、MVVM（Model-View-ViewModel）是三种常见的软件架构模式，它们的目标都是将应用程序的不同部分分脱离来，以进步代码的可维护性、可扩展性和可测试性。
MVC框架

MVC（Model-View-Controller）是一种软件架构模式，它将应用程序分为三个主要组件：模子（Model）、视图（View）和控制器（Controller）。
下面详细介绍MVC框架的各个组成部分及其作用：
MVC框架模式图：

• 模子（Model）：
  
  
  
  • 在 Android 中，模子通常代表应用程序的数据和业务逻辑。这可能包括从网络加载的数据、数据库中的数据或应用程序的状态信息等。模子通常由 Java 类或 Kotlin 类体现，并包含了获取、存储和操作数据的方法。模子通常与应用程序的后端服务进行交互，如 RESTful API 大概数据库。
    
  
  
• 视图（View）：
  
  
  
  • 视图代表用户界面的可视化部分。在 Android 中，视图通常由 XML 结构文件定义，可以包括各种 UI 组件，如按钮、文本框、列表视图等。视图的主要责任是将模子中的数据呈现给用户，并将用户的操作转发给控制器进行处理。视图应该尽可能被 passives，并且只负责体现数据，不包含任何业务逻辑。
    
  
  
• 控制器（Controller）：
  
  
  
  • 在 Android 中，控制器通常由 Activity 或 Fragment 扮演脚色。它们负责处理用户的输入事件，从视图中读取用户操作，并相应地更新模子或视图。控制器还可以负责和谐不同组件之间的交互，例如在模子更新后更新视图。
    
  
  

在 Android 中实现 MVC 框架通常遵照以下步骤：

• 创建模子：创建用于管理数据和业务逻辑的模子类。这可能包括定义数据结构、访问数据库或网络服务等。
  
• 创建视图：利用 XML 结构文件创建用户界面的视图部分。这些视图文件定义了应用程序的用户界面元素和结构。
  
• 创建控制器：创建 Activity 或 Fragment 类作为控制器，它们负责处理用户的输入和更新模子或视图。控制器通常会与模子类和视图文件进行交互，以实现业务逻辑和用户界面的更新。
  
• 毗连模子、视图和控制器：在控制器中初始化模子，并将模子的数据传递给视图进行体现。控制器还应该监听视图的用户输入事件，并根据用户的操作更新模子或视图。
  
• 维护代码分离和组织：保持模子、视图和控制器之间的分离，并遵照单一责任原则。这有助于代码的可维护性和可测试性，使得在应用程序变得复杂时更轻易管理和扩展。
  

只管 Android MVC 框架在肯定程度上可以资助组织和管理应用程序的代码，但它也有一些限制。例如，随着应用程序的复杂度增长，控制器可能变得过于臃肿，并且视图与模子之间的耦合度可能会增长。因此，一些开发者可能会选择更现代的架构模式，如 MVP（Model-View-Presenter）或 MVVM（Model-View-ViewModel）。
MVP框架

在 Android 开发中，MVP（Model-View-Presenter）是一种常用的架构模式，它是基于MVC模式的改进，旨在进一步分离应用程序的各个组件，进步代码的可测试性和可维护性。
下面是关于 Android 中 MVP 框架的详细介绍：
MVP框架模式图：

模子（Model）：

• 模子在 MVP 中的作用与在 MVC 中类似，代表应用程序的数据和业务逻辑。模子负责从数据源（如数据库、网络服务等）获取数据，并将数据返回给 Presenter。模子类通常是普通的 Java 类或 Kotlin 类，不直接依靠于 Android 框架。
  

视图（View）：

• 视图是用户界面的可视化体现，负责向用户体现数据并接收用户的操作。在 MVP 中，视图通常由 Activity 或 Fragment 实现，但它们的脚色仅限于负责视图的渲染和用户交互的相应，并不处理任何业务逻辑。视图通过接口与 Presenter 交互，Presenter 利用视图接口来更新视图的内容。
  

Presenter（Presenter）：

• Presenter 是 MVP 中最关键的部分，它充当了模子和视图之间的中间人，负责处理业务逻辑和和谐视图与模子之间的交互。Presenter 从模子中获取数据，并将数据格式化后传递给视图进行体现。Presenter 还接收视图的用户输入事件，根据输入更新模子并更新视图的状态。Presenter 与视图之间通过接口进行通信，这样做的目标是将视图与 Presenter 解耦，使得视图可以更加独立地进行单元测试。
  

在 Android 中实现 MVP 模式通常遵照以下步骤：

• 定义视图接口：创建一个视图接口，其中包含了视图所需的方法，如体现数据、体现加载中状态、体现错误信息等。这个接口通常在 Activity 或 Fragment 中定义。
  
• 创建 Presenter：创建一个 Presenter 类，实现与视图接口相对应的方法，并在这些方法中实现业务逻辑。Presenter 应该持有一个对视图接口的引用，以便与视图进行通信。
  
• 创建模子：创建模子类，负责从数据源中获取数据，并将数据返回给 Presenter。模子应该是独立于 Android 框架的普通 Java 类或 Kotlin 类。
  
• 毗连视图、Presenter 和模子：在视图中创建 Presenter 的实例，并将自身作为视图接口的实现传递给 Presenter。Presenter 同样持有模子的实例，以便获取数据并更新视图。
  
• 维护代码分离和组织：保持视图、Presenter 和模子之间的分离，遵照单一责任原则。这有助于代码的可维护性和可测试性，使得在应用程序变得复杂时更轻易管理和扩展。
  

MVP 框架的上风包括良好的代码分离、可测试性和可维护性。由于 Presenter 与视图之间的解耦，可以更轻易地编写单元测试，而不必要依靠于 Android 框架。此外，MVP 框架还提供了更清晰的分层结构，使得代码更易于明白和维护。
总的来说，MVP 框架是 Android 开发中常用的架构模式之一，特别适用于必要高度可测试性和可维护性的应用程序。
MVVM框架

在 Android 开发中，MVVM（Model-View-ViewModel）是一种架构模式，旨在进一步分离应用程序的各个组件，使得代码更加模块化、可测试和可维护。MVVM 模式在 Android 开发中通常与 Data Binding 和 LiveData 等 Jetpack 组件一起利用，以实现数据驱动的 UI 开发。
以下是关于 Android 中 MVVM 框架的详细介绍：
MVVM框架模式图：

模子（Model）：

• 模子在 MVVM 中的作用与在 MVC 或 MVP 中相似，代表应用程序的数据和业务逻辑。模子负责从数据源（如数据库、网络服务等）获取数据，并将数据提供给 ViewModel。模子通常是普通的 Java 类或 Kotlin 类，不依靠于 Android 框架。
  

视图（View）：

• 视图是用户界面的可视化体现，负责向用户体现数据并接收用户的操作。在 MVVM 中，视图通常是 Activity 或 Fragment，但它们不包含任何业务逻辑。视图只负责展示数据，不直接与模子交互。视图通过数据绑定技术与 ViewModel 进行绑定，当数据发生厘革时自动更新界面。
  

视图模子（ViewModel）：

• 视图模子是 MVVM 中最关键的部分，它充当了视图和模子之间的中间人，负责管理视图所需的数据和业务逻辑，并将这些数据和逻辑以适当的方式袒露给视图。ViewModel 包含了视图所需的各种状态和操作方法，如数据加载状态、数据列表等。ViewModel 通常包含 LiveData 或 ObservableField 等可观察数据对象，以便实现数据的动态更新。
  

在 Android 中实现 MVVM 模式通常遵照以下步骤：

• 创建模子：创建模子类，负责从数据源中获取数据，并将数据提供给 ViewModel。模子类通常是普通的 Java 类或 Kotlin 类，不直接依靠于 Android 框架。
  
• 创建视图：创建 Activity 或 Fragment，作为用户界面的可视化体现。视图负责展示数据，并与 ViewModel 进行绑定，以实现数据驱动的 UI 更新。在结构文件中利用 Data Binding 技术与 ViewModel 进行绑定。
  
• 创建视图模子：创建 ViewModel 类，负责管理视图所需的数据和业务逻辑。ViewModel 应该持有对模子的引用，并袒露 LiveData 或 ObservableField 等可观察数据对象，以便视图可以观察数据的厘革并及时更新界面。
  
• 毗连视图和视图模子：在视图中创建 ViewModel 的实例，并通过 ViewModelProviders 工具类获取 ViewModel 的引用。在视图中利用 Data Binding 技术将视图与视图模子进行绑定，以实现数据的双向绑定和自动更新。
  
• 维护代码分离和组织：保持视图、视图模子和模子之间的分离，遵照单一责任原则。这有助于代码的可维护性和可测试性，使得在应用程序变得复杂时更轻易管理和扩展。
  

MVVM 框架的上风包括良好的代码分离、可测试性和可维护性。由于视图和视图模子之间的双向绑定，可以更轻易地实现数据驱动的 UI 开发，同时还能够淘汰手动更新界面的代码量。此外，MVVM 框架还提供了更清晰的分层结构，使得代码更易于明白和维护。
总的来说，MVVM 框架是 Android 开发中常用的架构模式之一，特别适用于必要动态更新用户界面的应用程序。配合 Jetpack 组件中的 Data Binding 和 LiveData，可以更加轻松地实现 MVVM 架构，并构建出具有高度可测试性和可维护性的 Android 应用程序。
MVVM与MVP区别

MVVM（Model-View-ViewModel）和MVP（Model-View-Presenter）之间的主要区别在于视图模子（ViewModel）与Presenter的脚色和数据绑定机制。
脚色定名：

• 在 MVP 中，Presenter 充当了视图（View）和模子（Model）之间的中间人，负责处理用户输入、更新视图和管理业务逻辑。
  
• 在 MVVM 中，Presenter 被改名为 ViewModel。ViewModel 与 Presenter 有着相似的职责，但它更加专注于为视图提供所需的数据和操作，而不直接操作视图。
  

数据绑定：

• MVVM 模式引入了数据绑定机制，这是其与 MVP 的主要区别之一。数据绑定使得视图和视图模子之间的通信变得更加简单和直接。当视图中的数据厘革时，自动地更新到视图模子中，反之亦然。这意味着开发者不必要手动编写代码来处理视图和视图模子之间的数据交换，框架会自动完成这些工作。
  
• 在 MVP 中，通常必要手动编写代码来处理视图和 Presenter 之间的数据交换，例如通过接口来更新视图并将用户输入传递给 Presenter 进行处理。
  

依靠关系：

• 在 MVP 中，视图（View）和 Presenter 是相互依靠的，视图持有对 Presenter 的引用，并且通过接口与 Presenter 进行交互。
  
• 在 MVVM 中，视图（View）和 ViewModel 之间的依靠性相对较低。通常，视图不直接持有对 ViewModel 的引用，而是通过数据绑定来实现视图与 ViewModel 的交互。
  

测试性：

• 由于 MVVM 中的视图模子（ViewModel）更加专注于数据和业务逻辑，而且与视图之间的耦合度较低，因此通常更易于进行单元测试。
  
• 在 MVP 中，Presenter 与视图之间的交互较多，视图和 Presenter 之间的耦合度较高，可能必要利用 Mock 对象等技术来进行测试。
  

总的来说，MVVM 和 MVP 在核心概念上非常相似，但在数据绑定机制和视图模子的脚色定位上有所不同。MVVM 通过数据绑定机制简化了视图和视图模子之间的通信，使得开发更加高效，而 MVP 则更加注重视图和 Presenter 之间的交互。
MVVM与MVC区别

MVVM 实现了数据绑定机制，使得视图和模子之间的数据同步更加简单和自动化。这种数据绑定机制确实是 MVVM 模式的一个显著特征，而传统的 MVC 模式通常不包括这样的机制。
在 MVC 中，视图（View）与控制器（Controller）之间是通过触发事件、回调或其他手动方式来进行通信的。当模子（Model）的数据发生厘革时，开发者通常必要手动更新视图以反映这些厘革，这可能必要编写大量的代码来处理数据与视图之间的同步。
而在 MVVM 中，视图模子（ViewModel）作为视图（View）和模子（Model）之间的中间人，负责管理视图的状态和行为，并且通过数据绑定机制与视图进行毗连。当模子中的数据发生厘革时，视图模子会自动更新，并且这些厘革会自动反映到与其绑定的视图上，从而实现了数据与视图之间的自动同步。
这种数据绑定机制使得开发者不再必要手动编写大量的代码来处理数据与视图之间的同步，淘汰了重复代码的编写，进步了开发服从。同时，也使得代码更加清晰、简洁，降低了维护成本。
因此，MVVM 相对于 MVC 来说，更加适用于必要大量交互和动态更新的前端应用程序，特别是在必要实现复杂的用户界面时，MVVM 的数据绑定机制可以带来显著的上风。
MVC、MVP、MVVM模式哪个要好一些

推荐直接从该源码实例中下载项目源码，并在Android Studio中欣赏源代码并运行项目，这样便可详细地了解MVC、MVP、MVVM之间的区别与接洽。
1、MVC：

• 上风：MVC 是最传统的模式之一，易于明白和实现。对于简单的应用程序或团队成员熟悉的情况下，MVC 可能是一个不错的选择。
  
• 劣势：MVC 中控制器往往会变得臃肿，导致代码难以维护。视图和模子之间的耦合度较高，倒霉于单元测试。
  

2、MVP：

• 上风：MVP 将视图与模子完全解耦，进步了代码的可测试性和可维护性。Presenter 将业务逻辑从视图中抽离出来，使得视图更加轻量化。
  
• 劣势：MVP 可能增长了代码量，由于必要编写额外的 Presenter 层。对于团队成员熟悉 MVC 而不熟悉 MVP 的情况下，学习曲线可能较陡。
  

3、MVVM：

• 上风：MVVM 引入了数据绑定机制，简化了视图和视图模子之间的通信。视图模子可以直接对视图进行操作，而不必要通过控制器或 Presenter。这种模式适用于必要大量交互的前端应用程序。
  
• 劣势：MVVM 模式可能增长了复杂性，特别是对于初学者而言，学习数据绑定和视图模子可能必要一些时间。在某些情况下，数据绑定可能会导致性能问题。
  

综上所述，每种模式都有其适用的场景，没有一种模式是绝对优于其他模式的。在选择模式时，应该根据项目需求、团队技术水平和个人偏好进行衡量。
所以建议先学习MVC然后在此基础上慢慢发掘改进。然后再学习mvp大概mvvm吧。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。