MVC或MVP模式的区别

多年来我有辅导很多开发人员使用的设计模式和最佳实践。 一遍又一遍地不断涌现的一个问题是:什么是模型-视图-控制器(MVC)之间的差异和模型视图主持人(MVP)模式? 令人惊讶的答案是更复杂的比你会怀疑。 我认为许多开发人员回避的一部分原因使用不同模式的混乱。

之前我们深入研究差异研究模式的工作原理和使用的主要优点。 (MVC & MVP)模式已经使用了好几年,地址之间的关键即OO主要关注点分离UI和业务层。 今天有许多框架是使用基于这些模式包括:JAVA Struts,ROR,微软智能客户端软件工厂(出租车),微软网络客户端软件工厂,最近宣布ASP。 净MVC框架。

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

MVC模式是一种UI表示模式,着重于从业务层分离UI(视图)(模型)。 模式分离责任在三个部分:视图负责渲染UI元素,控制器负责响应用户界面操作,和模型负责业务行为和状态管理。 在大多数实现这三个组件可以直接相互作用和在一些实现控制器负责决定哪些视图来显示(前端控制器模式),

模型-视图-主持人(MVP)模式

 

MVP模式UI表示模式是基于MVC模式的概念。 模式分离责任四个组成部分:视图负责渲染UI元素,视图界面用于松散一些主持人从视图中,主持人负责视图和模型之间的交互,以及模型负责业务行为和状态管理。 在一些实现演讲者与服务(控制器)层进行交互检索/持久化模型。 视图界面和服务层一般用于让主持人和模型编写单元测试更容易。

关键好处

在使用任何模式开发人员需要考虑使用它的优点和缺点。 有许多关键的好处使用MVC或MVP模式(请参阅下面的列表)。 但是,也有一些画背需要考虑。 最大的缺点是额外的复杂性和学习曲线。 虽然模式可能不适合做简单的解决方案,推动解决方案可以大大受益于使用模式。 我我的经验已经看到几个解决方案消除了大量的复杂但重构使用模式。

 

·         松散耦合-主持人/控制器是一个UI代码和模型之间的媒介。 这使得视图和模型相互独立地进化。

·         清晰的关注点分离/责任

o    UI(或页面)——负责渲染UI元素

o    主持人/控制器-负责对UI事件和与模型进行交互

o    模型:负责业务行为和状态管理

·         测试驱动,通过隔离每个主要组件(UI、主持人/控制器和模型)更容易编写单元测试。 当使用MVP模式尤其如此,只有与视图使用接口。

·         代码重用,通过使用一个关注点分离/负责设计方法你将会增加代码重用。 尤其是当使用一个全面的域模型和保持所有的业务/状态管理逻辑的属于他们的权利。

·         隐藏数据访问——使用这些模式迫使你把数据访问代码,它属于一个数据访问层。 有一些其他的模式,典型的MVP / MVC模式适合数据访问。 两种最常见的是库和工作单元。 (见马丁-模式的企业应用程序的体系结构的更多细节)

·         灵活性/适应能力——通过孤立你的代码到主持人/控制器和模型组件代码库更能适应变化。 例如考虑多少用户界面和数据访问技术改变了多年来和我们今天使用的选择的数量。 一个正确设计方案使用MVC或MVP可以支持多用户界面和数据访问技术在同一时间。

关键的不同点

所以真正MVC和MVP模式之间的差异。 其实他们之间存在着很多差异。 这两种模式关注跨多组件分离的责任,促进松散耦合UI(视图)从业务层(模型)。  主要的差异是模式是如何实现的,并在一些先进的场景需要主持人和控制器。

 

这里有之间的关键差异模式:

 

·         MVP模式

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

o    单元测试更容易,因为交互视图是通过一个接口

o    通常主持人一一对应。 复杂的视图可能多主持人。

 

·         MVC模式

o    控制器是基于行为和可以在视图之间共享

o    可以负责决定哪些视图来显示(前端控制器模式)

 

希望你觉得这篇文章很有趣,它帮助澄清MVC和MVP模式之间的差异。 如果没有,也不要惊惶模式是强大的工具,可以有时难以使用。 要记住的一件事是,一个模式是一个蓝图和不是一个开箱即用的解决方案。 开发人员应该使用它们作为指导和修改实现根据他们的问题域。