MVP 框架与 MVC 框架究竟有何区别

Posted 2021-05-01 研发云

在软件中，要创建和修改内部数据

必须有业务逻辑的支持

而数据的显示也需要界面技术的支持

在经典的MVC框架模式中

View会直接从Model里读取数据

而不是通过 Controller

由于View可以直接访问Model

因此在其中会有很多Model层的信息存在

不可避免的还要包括一些业务逻辑

但软件业务逻辑和视图间的耦合度太高

有时并不利于对其进行调试

也较为影响框架模块的重用性

而MVP 框架模式的出现

就是为了进一步解决这个问题

实现模块与模块之间的低耦合

MVP从MVC框架演变过来

它与MVC有一定的相似性

即Model提供数据，View负责显示

但与MVC不同的是

在“负责逻辑处理”的这部分组件上

由Controller（控制器）

换成了Presenter（交互）

而且改变的不仅是模块，还有通信方向

其目的是为了把Model和View完全隔离开

让他们单独变化

可以说，MVP是一个真正意义上的

能隔离View细节和复杂性的框架模式

MVP架构模式的实现原理

在MVC框架模式中，View可以有多重表现形式（例如：UI界面、html页面、XAML文件或者winform界面等等），但是在MVP框架模式中，情况完全不同。MVP模式将View层的接口提取出来以后，让Presenter依赖这个接口去更新View。这样Presenter就不用依赖真正的视图界面，任何实现了该接口的界面，都能够复用已有的Presenter和Model代码。

MVP框架模式的View层绝不容许直接访问Model，Model层会把想要更新View的操作委托Presenter去操作，而Presenter层从Model中获取数据并提供给View层，Presenter还负责处理后台任务。它会把更新View的操作交给View层对象去操作。

MVP 模式的主要优点

1、模型与视图完全分离，从而显著增加了模块复用性。用户可以只修改视图而不影响框架的其它部分。

2、可以更高效地使用框架，因为所有的交互都发生在Presenter内部，所以可将一个Presenter用于多个视图，而不需要改变Presenter的逻辑（在实际使用过程中，视图的变化总是比整体框架的变化要频繁）

3、由于逻辑处理被置于Presenter中，因此可以脱离用户接口来测试相应的业务逻辑（单元测试），比如开发者可以通过接口模拟View层的各种操作，来实现对Presenter的测试 —— 而不需要使用自动化的测试工具。

长｜按｜二｜维｜码｜关｜注

获取更多产品介绍及业界动态

研发云微信公众号

移动Labs公众号

 研·发·云