MVC或MVP模式 - 有什么区别？

原文地址:https://www.infragistics.com/community/blogs/b/todd_snyder/posts/mvc-or-mvp-pattern-whats-the-difference

多年来，我已经为许多开发人员提供了使用设计模式和最佳实践的指导。一个不断出现的问题是：模型视图控制器（MVC）和模型视图演示者（MVP）模式之间有什么区别？令人惊讶的是，答案比你想象的要复杂得多。部分原因我认为许多开发人员不愿意使用这两种模式，这是对差异的混淆。

在深入分析之前，我们来看看这些模式是如何工作的，以及使用这两种模式的关键好处。两种（MVC和MVP）模式已经使用了好几年了，并且解决了一个关键的OO原则，即UI和业务层之间的关注点分离。现在有许多基于这些模式的框架，包括：JAVA Struts，ROR，Microsoft智能客户端软件工厂（CAB），Microsoft Web客户端软件工厂以及最近宣布的ASP.Net MVC框架。

模型视图控制器（MVC）模式

MVC模式是一种UI呈现模式，侧重于将UI（View）与业务层（Model）分离。该模式将职责分为三个部分：视图负责重用UI元素，控制器负责响应UI操作，模型负责业务行为和状态管理。在大多数实现中，所有三个组件可以直接相互交互，并且在一些实现中，控制器负责确定显示哪个视图（前端控制器模式），

模型视图演示者（MVP）模式

 

MVP模式是基于MVC模式的概念的UI呈现模式。该模式将职责分为四个部分：视图负责重用UI元素，视图接口用于松散地将主持人从视图中耦合出来，主持人负责视图/模型之间的交互，模型负责业务行为和国家管理。在一些实现中，演示者与服务（控制器）层交互以检索/保持模型。视图界面和服务层通常用于为演示者和模型编写单元测试。

主要优点

在使用任何模式之前，开发者需要考虑使用它的优点和缺点。使用MVC或MVP模式有许多关键好处（请参阅下面的列表）。但是，还有几点可以考虑。最大的缺点是额外的复杂性和学习曲线。虽然模式可能不适合简单的解决方案; 先进的解决方案可以大大受益于使用模式。我是我的经验，已经看到一些解决方案消除了大量的复杂性，但重新考虑使用任何模式。

 

·         松耦合 - 演示者/控制器是UI代码和模型之间的中介。这允许视图和模型相互独立地演变。

·         关注明确分工/责任

ø    UI（表单或页面） -负责撕掉UI元素

o    演示者/控制者 - 负责响应UI事件并与模型进行交互

o    模型 - 负责商业行为和国家管理

·         测试驱动 - 通过隔离每个主要组件（UI，Presenter /控制器和模型），编写单元测试更容易。当使用仅通过接口与视图进行交互的MVP模式时，情况尤其如此。

·         代码重用 - 通过使用关注点分离/负责任的设计方法，您将增加代码重用。当使用完整的域模型并将所有业务/状态管理逻辑保留在其所在的位置时，尤其如此。

·         隐藏数据访问 - 使用这些模式会迫使你将数据访问代码放在数据访问层所在的位置。还有一些典型的MVP / MVC模式用于数据访问的其他模式。其中最常见的两个是存储库和工作单元。（有关更多详细信息，请参阅Martin Fowler - 企业应用程序体系结构的模式）

·         灵活性/适应性 - 通过将大部分代码隔离到演示者/控制器和模型组件中，代码库更适合于更改。例如，考虑多少年来用户界面和数据访问技术发生了变化，以及我们今天可以选择的选择数量。使用MVC或MVP的正确设计解决方案可以同时支持多种UI和数据访问技术。

主要差异

那么MVC和MVP模式之间究竟有什么区别？其实他们之间并没有太多的分歧。这两种模式都侧重于跨多个组件的职责分离，并促进从业务层（模型）松散耦合UI（视图）。  主要区别在于模式是如何实现的，在一些高级场景中，您需要演示者和控制器。

 

以下是模式之间的主要区别：

 

·         MVP模式

o    视图更松散地耦合到模型。主持人负责将模型绑定到视图上。

o    更容易进行单元测试，因为与视图的交互是通过界面进行的

o    通常查看演示者映射一对一。复杂的观点可能有多个主持人。

 

·         MVC模式

o    控制器基于行为，可以在视图中共享

o    可以负责确定显示哪个视图（前端控制器模式）