当超越RAD(拖放和配置)构建用户界面的方式时,许多工具都鼓励您使用三种设计模式,即模型视图控制器、模型视图演示器和模型视图视图模型。我的问题有三个部分:
这些模式解决了什么问题?它们有什么相似之处?它们有何不同?
当超越RAD(拖放和配置)构建用户界面的方式时,许多工具都鼓励您使用三种设计模式,即模型视图控制器、模型视图演示器和模型视图视图模型。我的问题有三个部分:
这些模式解决了什么问题?它们有什么相似之处?它们有何不同?
当前回答
这两个框架都旨在分离关注点-例如,与数据源(模型)的交互、应用程序逻辑(或将这些数据转换为有用信息)(控制器/演示者)和显示代码(视图)。在某些情况下,模型还可以用于将数据源转换为更高级别的抽象。MVC Storefront项目就是一个很好的例子。
这里讨论了MVC与MVP之间的区别。
所做的区别在于,在MVC应用程序中,视图和控制器传统上与模型交互,而不是彼此交互。
MVP设计让演示者访问模型并与视图交互。
尽管如此,根据这些定义,ASP.NET MVC是MVP框架,因为控制器访问模型以填充视图,这意味着没有逻辑(只显示控制器提供的变量)。
要了解ASP.NET MVC与MVP的区别,请查看Scott Hanselman的MIX演示。
其他回答
MVP
MVP代表模型-视图-演示者。2007年初,微软推出了Smart Client windows应用程序。
演示者在MVP中充当监督角色,MVP绑定模型中的视图事件和业务逻辑。
视图事件绑定将从视图界面在Presenter中实现。
视图是用户输入的发起者,然后将事件委派给演示者,演示者处理事件绑定并从模型中获取数据。
赞成的意见:视图只有UI,没有任何逻辑高水平的可测试性
欺骗:实现事件绑定时有点复杂,工作量更大
MVC
MVC代表模型视图控制器。控制器负责创建模型并使用绑定模型渲染视图。
控制器是启动器,它决定渲染哪个视图。
赞成的意见:强调单一责任原则高水平的可测试性
欺骗:如果试图在同一控制器中渲染多个视图,有时控制器的工作量太大。
这两种模式都试图分离表示和业务逻辑,将业务逻辑与UI方面分离
在架构上,MVP是基于页面控制器的方法,而MVC是基于前端控制器的方法。这意味着MVP标准的web表单页面生命周期只是通过从代码后面提取业务逻辑来增强的。换句话说,page是为http请求提供服务的页面。换句话说,MVP IMHO是一种网络形式的进化型增强。另一方面,MVC完全改变了游戏,因为在加载页面之前,请求被控制器类拦截,在那里执行业务逻辑,然后在控制器处理刚刚转储到页面的数据的最终结果(“视图”)从这个意义上讲,MVC看起来(至少在我看来)很像MVP的Supervisory Controller风格,它通过路由引擎增强了MVP的功能
这两种方法都支持TDD,并有其优缺点。
关于如何选择其中一个IMHO的决定应该基于在ASP.NET web表单类型的web开发中投入的时间。如果有人认为自己擅长网络形式,我会建议MVP。如果你在页面生命周期等方面感觉不太舒服的话,MVC可能是一种方法。
下面是另一个博客文章链接,提供了关于这个主题的更多细节
http://blog.vuscode.com/malovicn/archive/2007/12/18/model-view-presenter-mvp-vs-model-view-controller-mvc.aspx
这两个框架都旨在分离关注点-例如,与数据源(模型)的交互、应用程序逻辑(或将这些数据转换为有用信息)(控制器/演示者)和显示代码(视图)。在某些情况下,模型还可以用于将数据源转换为更高级别的抽象。MVC Storefront项目就是一个很好的例子。
这里讨论了MVC与MVP之间的区别。
所做的区别在于,在MVC应用程序中,视图和控制器传统上与模型交互,而不是彼此交互。
MVP设计让演示者访问模型并与视图交互。
尽管如此,根据这些定义,ASP.NET MVC是MVP框架,因为控制器访问模型以填充视图,这意味着没有逻辑(只显示控制器提供的变量)。
要了解ASP.NET MVC与MVP的区别,请查看Scott Hanselman的MIX演示。
不久前,我在博客中引用了托德·斯奈德(Todd Snyder)关于两者区别的精彩文章:
以下是模式:MVP模式视图与模型的耦合更加松散。演示者是负责将模型绑定到视图。更容易进行单元测试,因为与视图的交互是通过的接口通常视图到演示者的映射是一对一。复杂视图可能具有多主持人。MVC模式控制器基于行为,可以在意见可以负责确定要显示的视图
这是我能在网上找到的最好的解释。