这篇文章是我近期对MVC和MVP的一些思考,在使用MVC/MVP模式的过程中曾经走过一些弯路。现在虽然改正了某些弯路,但不保证改正了所有的弯路(例如对渲染的理解),所以请阅读这篇文章的朋友不吝发挥你们的质疑。
写这篇文章也是想知道自己还有什么地方是错的,我的最终方案是否可行?
有交流才会有进步。你有一个苹果,我有一个苹果,我们交换后仍各有一个苹果,你有一个思想,我有一个思想,我们交换后......会有N个思想 :p
1. MVC的理解误区
以下是我以前对MVC模式的理解误区:
1. 认为Model是指失血模型的实体类(Entity),是作为View和Controller之间的传输数据。
2. 把业务逻辑全部放在Controller端,认为Controller是用来写UI的业务逻辑的。
这两个误区本质上都是对Model的作用不明导致的。
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的一些思考
最新推荐文章于 2024-08-17 19:13:55 发布