zoukankan      html  css  js  c++  java
  • MVC和MVP

    MVC和MVP的一些思考

    碧落

     

    前言

    这篇文章是我近期对MVC和MVP的一些思考,在使用MVC/MVP模式的过程中曾经走过一些弯路。呵呵,现在虽然改正了某些弯路,但不保证改正了所有的弯路(例如对渲染的理解),所以请阅读这篇文章的朋友不吝发挥你们的质疑。

     

    写这篇文章也是想知道自己还有什么地方是错的,我的最终方案是否可行?

    有交流才会有进步。你有一个苹果,我有一个苹果,我们交换后仍各有一个苹果,你有一个思想,我有一个思想,我们交换后......会有N个思想 :p

    1. MVC的理解误区

    以下是我以前对MVC模式的理解误区:

    1. 认为Model是指失血模型的实体类(Entity),是作为ViewController之间的传输数据。

    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#中使用事件解决ViewController的交互。

    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,而且框架上更“干净”,开发人员写起来更自由。

     

     

    一些零碎的想法,有什么错误的地方请大家多多指教,谢谢。

  • 相关阅读:
    20155313 杨瀚 《网络对抗技术》实验九 Web安全基础
    20155313 杨瀚 《网络对抗技术》实验八 Web基础
    20155313 杨瀚 《网络对抗技术》实验七 网络欺诈防范
    20155313 杨瀚 《网络对抗技术》实验六 信息搜集与漏洞扫描
    20155313 杨瀚 《网络对抗技术》实验五 MSF基础应用
    20155313 杨瀚 《网络对抗技术》实验四 恶意代码分析
    20155313 杨瀚 《网络对抗技术》实验三 免杀原理与实践
    20155313 杨瀚 《网络对抗技术》实验二 后门原理与实践
    20155313 杨瀚 《网络对抗技术》实验一 PC平台逆向破解(5)M
    20155313 2017-2018-1 《信息安全系统设计基础》课程总结
  • 原文地址:https://www.cnblogs.com/shineblog/p/2459619.html
Copyright © 2011-2022 走看看