MVP模式实现了View Interface,让Controller代码从View层很好的分离出来,逻辑也更清晰。这个和传统的Page_Load的面条代码相比,有很明显的进步。采用MVP模式之后,Page_load里的代码明显减少了。对于网站开发而言,你可以在dll里写出控制器代码和视图的接口了,以后页面的具体布局,风格也就可以少抄心很多了。但是新问题也产生了:
1、Presenter 中往往有好多种状态,比如简单的登陆界面,至少有3个状态:登陆前,登陆错误,登陆成功。是应该把这3个状态做成一个View Interface,还是做成3个独立的View Interface呢?按照OO的原则,类应该保持单一的职责,所以选中3个独立的View Interface。但是这个在Asp.net中实现起来好像并不容易。如果设计成一个,那么在View 中,必然存在很多的if,这里简单的称为 界面逻辑。如果状态多了,这些界面逻辑也可能成为一堆面条。所以这里是一个问题。我也看过类似 Response.Redirect的方案,这个增加了Http请求的数目。
可能的解决办法,是让Presenter支持多个View,增加自动加载视图的功能,类似CakePhp。
2、事件中调用Presenter的代码问题。如果有一个比较复杂的页面,可能有多个Presenter类,并且页面会响应很多事件。但是如果要仔细的区分这些事件,在Asp.net如果不采用WebControl,做起来就比较的麻烦。因为HtmlControl和Html代码之类的都支持 回发事件,并且在Asp.net中操作不方便。
以上是我想到的2个问题,也是在实际使用中感觉需要改进的问题。总体来说,MVP模式是基于Asp.net的事件模型的重大改进啊,如果你现在还为Page_Load,OnClick中的重复代码、复杂逻辑感到发愁,建议了解一下MVP模式。
参考:
http://www.codeproject.com/useritems/Advanced_MVP.asp
相关文章
- 我希望来年,更多是靠关系和模式挣钱——2022年我的总结与思考 n年前,我没钱但年轻,我怕n年后我老时,还是一无所成——2017我的收获和反思 2018我跳出了舒适区,发现自己缺的不仅是技术,另外还得探索其它挣钱渠道 2019我获得的些许成绩,能不能弥补这一年光阴的流逝?盘点2019我的得失 我不想安于当前的限度,以达到所谓的幸福,回顾下2020年的我 今年我拿到了期望中的收入,同时更希望能在睡后收入上有进一步的发展——2021年我的总结与思考
- 浅析MVP模式中V-P交互问题及案例分享
- android中MVP或者说mvp模式的使用及思想分解,mvp和mvc的区别
- 浅谈开发中的MVVM模式及与MVP和MVC的区别
- ISAPI和CGI限制中没有ASP.NET v4.0 ; vS2013检测到在集成的托管管道模式下不适用的 ASP.NET 设置。
- MVP模式中的P和V关系
- 关系数据库中的目录和模式有什么区别?