浅析MVC，MVP，MVVM与其联系

目录

本文中的图片来自博主 小孟来码

MVC

MVC架构是一种常见的软件设计模式，在许多应用程序中都得到了广泛应用。MVC是三个单词的首字母缩写，它们是Model（模型）、View（视图）和Controller（控制），它将应用程序分为三个核心组成部分：模型（Model）、视图（View）和控制器（Controller），以此来促进代码的重用性、灵活性和可维护性。

模型（Model）：模型代表应用程序的数据结构和业务逻辑。业务流程的处理过程对其它层来说是黑箱操作，模型接受视图请求的数据，并返回最终的处理结果。业务模型的设计可以说是MVC最主要的核心。模型通常不直接与用户界面交互，而是通过控制器来进行操作。在MVC架构中，模型应该是独立于具体实现的，以便于依赖注入和单元测试。

视图（View）：视图是用户界面的表示，负责向用户展示数据并接收用户的输入。视图可以是任何形式的用户界面，如网页、移动应用界面或桌面应用界面。视图根据模型的数据来渲染内容，并将用户的操作传递给控制器。在MVC架构中，视图的职责是尽可能小，只负责展示数据和接收用户的操作，而不应该包含复杂的业务逻辑。比如一个订单的视图只接受来自模型的数据并显示给用户，以及将用户界面的输入数据和请求传递给控制和模型。

控制器（Controller）：控制器充当模型和视图之间的中介，负责处理用户输入、更新模型数据，并相应地更新视图。控制器接收用户的操作请求，然后调用模型来处理数据逻辑，并最终选择合适的视图来显示最新的数据。在MVC架构中，控制器应该是独立于视图和模型的，以便于单元测试和代码重用。

假如一个应用程序是一个餐厅，那么模型是厨房，负责具体功能的实现，视图是餐桌，是使用者的看到的东西，控制器是服务员。协调后台制作和前台提供服务，

1. 视图（View）：视图位于最顶层，负责展示数据给用户。视图从控制器获取数据，并将数据呈现给用户。用户的操作和输入会通过视图传递给控制器。
2. 控制器（Controller）：控制器位于中间层，充当模型和视图之间的桥梁。它接收来自视图的用户输入和操作，，并接收用户的输入，并根据业务逻辑对模型进行更新或查询。控制器还负责将更新后的数据发送给视图进行展示。
3. 模型（Model）：模型位于最底层，负责存储应用程序的数据和处理业务逻辑。它可以是数据库、文件系统或其他数据存储方式。模型提供了数据的读取、写入和修改等操作方法，供控制器使用。

这里注意他并不是一个单纯的类似于线性的关系，而是一个树的模式，当用户输入数据时，该数据首先被送到视图。视图将用户输入传递给控制器，控制器再决定将数据传递给哪个模型进行处理。模型处理完数据后，将结果返回给控制器，控制器再将结果传递给视图进行展示。这个过程中涉及到多个节点之间的交互，因此可以看作是一个树形结构。

这三层是紧密联系在一起的，但又是互相独立的，每一层内部的变化不影响其他层。每一层都对外提供接口（Interface），供上面一层调用。这样一来，软件就可以实现模块化，修改外观或者变更数据都不用修改其他层，这种层级关系和联系方式使得MVC架构在应用程序中实现了数据、展示和用户交互的分离，提高了代码的可维护性和扩展性。

优点：：

1. 耦合性高，生命周期成本低，部署快，可维护性高，适用于快速开发的小型项目

缺点：
不适合大型，中等项目，View层Controller层连接过于紧密
View层对Model层的访问效率低
一般的高级UI页面工具和构造器不支持MVC模式

MVP

MVP（Model-View-Presenter）是一种软件架构模式，用于组织应用程序的代码和逻辑。它是在MVC模式的基础上演变而来，主要解决了MVC模式中视图和模型之间的紧耦合问题。

在MVP架构中，模型（Model）负责处理数据和业务逻辑，视图（View）负责用户界面的展示，而表示器（Presenter）则充当了视图和模型之间的中介者。具体的职责如下：

1. 模型（Model）：负责处理数据和业务逻辑，与MVC模式中的模型相同。

2. 视图（View）：负责用户界面的展示，但不负责处理用户事件或数据操作。视图中通常会包含一些接口（Interface），用于定义与表示器交互的方法。

3. 表示器（Presenter）：作为视图和模型之间的中介者，负责处理用户事件、数据操作和业务逻辑。它从视图接收用户输入，并将其转发给模型进行处理。当模型返回结果时，表示器将结果传递给视图，以更新界面展示。
   

相较于MVC模式，MVP模式的主要区别在于引入了表示器，使得视图和模型之间的耦合度降低。表示器充当了视图和模型之间的桥梁，通过接口的方式进行通信，使得视图和模型可以独立地进行开发和测试。这样的设计使得代码更加可维护、可扩展，并且方便进行单元测试。

在MVC模式中，视图负责用户界面的展示，模型负责处理数据和业务逻辑，而控制器充当了视图和模型之间的中介者。视图将用户的输入传递给控制器，控制器根据业务逻辑更新模型，并将更新后的数据传递给视图进行展示。这种模式下，视图和模型之间存在直接的耦合关系，即视图需要知道模型的存在和具体实现细节。

而在MVP模式中，表示器（Presenter）取代了控制器的角色，成为视图和模型之间的中介者。视图负责用户界面的展示，但不处理任何业务逻辑，它通过接口向表示器传递用户的输入。表示器接收到用户输入后，根据业务逻辑更新模型，并将更新后的数据传递给视图进行展示。在这种模式下，视图不直接依赖于具体的模型实现，它只需要通过接口与表示器进行通信。这样一来，视图和模型之间的耦合度降低了，因为它们之间的交互通过表示器进行，并且视图不需要了解模型的具体实现细节。

总结一下，MVC模式中的控制器主要负责处理用户的输入和业务逻辑的实现，而MVP模式中的表示器则更加强调从视图中抽象出业务逻辑，并负责处理用户交互、更新模型、传递数据和事件等操作。表示器在一定程度上承担了控制器和视图之间的角色，具有更紧密的交互和协作。 在MVP模式中，Model与View无法直接进行交互，所以Presenter层会从Model层获得数据，适当处理后交给View层进行显示
在MVP模式中，Presenter层将View层和Model层进行隔离，使View和Model之间不存在耦合，同时将业务逻辑从View层剥离

优点：

1. 模型与视图完全分离，修改视图不会影响模型。
2. 可以更高效地使用模型，因为所有的交互都发生在一个地方——Presenter内部。
3. 可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑。
4. 可以脱离用户接口来测试逻辑（单元测试）。

缺点：

1. 视图和Presenter的交互会过于频繁，使得他们的联系过于紧密。也就是说，一旦视图变更了，presenter也要变更。
2. MVP需要编写更多的代码，因为需要编写Presenter层。
3. 对于小型应用程序，MVP可能会过于复杂。

MVVM

MVVM是Model-View-ViewModel的缩写，是一种软件架构模式。在MVVM中，Model代表应用程序的数据和业务逻辑，View代表用户界面，ViewModel则是View和Model之间的连接器，负责处理View与Model之间的交互，以及将数据从Model转换成View所需要的格式。MVVM的设计目标是将用户界面的逻辑与界面本身分离，使得代码更易于维护和测试。

M——Model（模型）实体模型，定义实体类，获取业务数据模型，如通过数据库或者网络来操作数据等
V——View（视图）布局文件(XML），主要进行控件的初始化设置
VM——ViewModel（控制器）：连接 View 与 Model 的中间桥梁，ViewModel 与 Model 直接交互，通过DataBinding将数据变化反应给View

总结

当从MVC（Model-View-Controller）演变到MVP（Model-View-Presenter），再到MVVM（Model-View-ViewModel）时，是一个逐步将逻辑与视图分离的过程。

在MVC中，模型（Model）负责存储数据和业务逻辑，视图（View）负责用户界面的展示，控制器（Controller）充当模型和视图之间的协调者。但是，视图和控制器之间的关系紧密耦合，导致视图难以独立测试和重用。

为了解决这个问题，MVP模式引入了Presenter层。在MVP中，模型仍然负责数据和业务逻辑，视图负责用户界面的展示，而Presenter则作为视图和模型之间的中介，处理用户输入和更新视图。这样一来，视图和模型可以更加独立地进行测试和开发。

而在MVVM中，ViewModel扮演了Presenter的角色，它进一步将视图与模型解耦。ViewModel包含视图所需的所有数据和逻辑，而视图则负责将ViewModel的状态反映到用户界面上。这种绑定机制使得视图的更新可以自动反映ViewModel的变化，大大简化了视图和ViewModel之间的交互。此外，MVVM还引入了数据绑定和命令绑定等概念，使开发者能够更方便地处理用户输入和事件响应。

总结起来，从MVC到MVP再到MVVM的过程是逐步将逻辑与视图分离的演化过程。这种演化使得视图能够更加独立、可测试和可重用，提高了代码的可维护性和开发效率。同时，通过引入Presenter或ViewModel层，进一步降低了视图与模型之间的耦合，实现了更紧凑和清晰的架构。