前言
这篇文章是我近期对MVC和MVP的一些思考,在使用MVC/MVP模式的过程中曾经走过一些弯路。呵呵,现在虽然改正了某些弯路,但不保证改正了所有的弯路(例如对渲染的理解),所以请阅读这篇文章的朋友不吝发挥你们的质疑。
写这篇文章也是想知道自己还有什么地方是错的,我的最终方案是否可行?
有交流才会有进步。你有一个苹果,我有一个苹果,我们交换后仍各有一个苹果,你有一个思想,我有一个思想,我们交换后......会有N个思想
1. MVC的理解误区
以下是我以前对MVC模式的理解误区:
1. 认为Model是指失血模型的实体类(Entity),是作为View和Controller之间的传输数据。
2. 把业务逻辑全部放在Controller端,认为Controller是用来写UI的业务逻辑的。
这两个误区本质上都是对应用开发中,Model的作用不明导致的。还有就是应用开发的mvc和web开发mvc开发之间的不同,在web开发中,逻辑是写在controller中的,而应用开发逻辑则是在model中,controller是用来对消息进行分发的
Model在MVC架构中起的作用非常重要,它才是UI业务逻辑真正的实现层。所以Model的实际上是Business Model(业务模型)。
而Controller仅仅起一个“桥梁”作用,它负责把View的请求转发给Model,再负责把Model处理结束的消息通知View。Controller就是一个消息分发器。Controller是用来解耦View和Model的,具体一点说,就是为了让UI与逻辑分离(界面与代码分离)。
2. MVC与VCP的区别
MVC的View直接与Model打交道,Controller只转发请求(View的请求)和通知(Model处理完之后的通知),不传递数据(业务结果),而是由View直接向Model拿数据。
MVP的View不与Model直接联系,所有的请求、结果通知、数据传递都是通过Controller转发,View和Model彼此不知道对方的存在。
3. MVC与MVP的相同点
无论是MVC还是MVP,View和Controller都是紧密联系的,在WinForm模式下更显得突出,View和Controller直接绑定在一起了(在一个类里面)。
MVC/MVP都是通过“通知”机制(观察者模式,在C#中使用事件)来解决View和Controller的交互。
4. MVP框架的设计
在MVP框架里,用Presenter代替MVC的Controller,而且View不再与Model交互。
4.1. Presenter
Presenter的作用比Controller大得多,Controller只是一个纯粹的消息分发器,而Presenter还负责传递Model的处理结果给View,并指导View的渲染。
注意,渲染我理解为UI的展现方式。
4.2. Presenter与Model
Presenter与Model使用接口隔离,Presenter直接调用Model的接口方法(比如IUserModel的FetchUserList()、SaveUser()等)。
4.3. Presenter与View
View与Presenter的交互使用观察者模式,有两种方式实现:
1. View主动使用Presenter。
View主动构造Presenter,并在内部调用Presenter的方法。即先有View再有Presenter。这种情况下,View明确知道自己要使用哪些Presenter。
2. Presenter主动使用View。
Presneter主动创建View,View里面定义有一堆的事件,Presenter注册这些事件。这种情况下,View不知道自己会被哪些Presenter使用。
第二种方式比第一种方式耦合性低,但View里要写一堆的事件,Presenter类里要捕获一堆的事件,感觉写起来很烦琐,代码不雅观。
5. Controller/Presenter的意义
以下Controller/Presenter简称为C/P。
C/P存在的意义是为了解耦View和Model。如果C/P不存在的话,View就直接访问Model,而View的变化是频繁的,不同的系统,View的展现方式不一样,让Model去控制View的渲染,会降低Model的重用性。如果Model不管View的渲染,由View自己渲染,那么就是WinForm的解决方式,即View和C/P经绑定(合并为一个类)。
6. 为什么要用MVC/MVP模式?
老实说,到目前为止,我依然看不出WinForm把Model分离之后,与标准的MVC/MVP有什麽差距。在WinForm分离Model之后,两者的交互可以用接口隔离,也可以用观察者模式让Form与Model一对多。再用IoC替代View直接构造Model的实例,那么WinForm代表的View+C/P(Form)已经与Model完全解耦了,View+C/P层连Model层都不需要引用(但要引用IModel层)。
这里关键是使用IoC技术,否则WinForm确实会导致View与Model直接耦合,更换Model,或者改变Model的接口会导致View要修改。注意,我们分离出来的Model,并不完全是为了使UI与代码分离,我们更注重Model的重用性,力求一个Model被多个View享用,甚至是不同系统的View享用。这就要求我们改动View的渲染时不用改动Model,同样地,我们改动Model的内部逻辑时,也不影响View的渲染。
嗯,或许还有一点:View通过Controller/ Presenter交互,使得系以统可以有一个共同的“入口”,系统可以在入口处做拦截,利于日志和权限的处理。但我们可以用AOP技术替代C/P的入口。
7. 新方案
由此看来,IoC+AOP可以完全替代C/P,而且框架上更“干净”,开发人员写起来更自由。
一些零碎的想法,有什么错误的地方请大家多多指教,谢谢。
相关推荐
MVC和MVP的区别
Android mvc+mvp+mvvm项目实现示例,简单说明。Android如何在项目中实现mvc、mvp、mvvm这三种模式。
本demo里主要以理论+代码的方式来依次讲解MVC、MVP以及MVVM三种框架,以及他们各自的优缺点,还有一部分是DataBinding的基本使用。
从mvc平滑过渡到mvp示例,详情请看博客 博客地址:http://blog.csdn.net/yuzhiqiang_1993/article/details/79082234
包含一个PPT(mvc->mvp->mvvm的概念,优缺点),一份源码(观察者模式,事件系统,mvc,mvp,mvvm的demo)
Android中MVC、MVP和MVVM的使用,区别,以及使用场景
MVC MVP MVVM
mvc mvp mvvm
只要一份简单的代码,就能够让你彻底的了解如何通过MVC和MVP模式去开发你自己的项目,你值得拥有!
分别用mvc,mvp,mvvm三种架构实现同一功能的android项目,比较三个架构的不同及优缺点。
通过java语言编写的一个Android程序,项目中围绕着MVC/MVP和MVVM架构设计,功能完整,注释齐全,同一个需求,同一套布局,同样的功能,不同的架构设计,只需要一个积分,你值得拥有!
MVC和MVP在 android上的实现 代码逻辑简单,适合移植在任何系统上。
PPT的形式展示Android 常用架构(MVC、MVP和MVVM) 简单明了 包含例题以及文字解释 对于刚上路的朋友 不懂架构的 可以下载看看 自己学习一下 有助于项目优化 对后期拓展有很大的帮助!
移动端MVC-MVP架构简单示例-Android
2013年五月下旬,2013年上半年学习ef的群体越来越多了,接到公司的要求,对公司的现有架构进行优化,围绕易用性,可拓展性,可维护性,高性能,高开发效率,团队学习难易度迅速定位的一个综合文档,对比mvc和mvp以及...
Android MVC+MVP设计模式结合项目运用,由于上传大小限制,这是第一部分
AndroidMvc, Android MVC/MVP/MVVM 框架 AndroidMvc框架 特性易于实现 MVC/MVP/MVVM Pattern 用于Android开发增强的Android生命周期- 比如 视图需要刷新时,但不需要旋转,onResume() 不足以区分两个场景。
MVC-MVP-MVVM实例
MVC, MVP和MVVM的区别和联系,是一个老生常谈的问题, 这里也不过多的进行描述 可以先查看下以下的两个链接: MVC,MVP 和 MVVM 模式如何选择? 你真的理解了MVC, MVP, MVVM吗? 其中第一篇文章是比较偏理论的分析, 第...
mvc、mvp及mvvm设计模式初步调查,View::对应于xml布局文件 Model:实体模型 Controllor:对应于Activity业务逻辑,数据处理和UI处理