混乱的MVC,.NET非要MVC不可么?

最近流行MVC,不是因为大家都在用,而是他已经在.NET缺席N多年。本文题目是乱取的,吸引眼球而已

MVC是一个非常有争议性的话题,首先,什么算是MVC,没有一个统一的说法,众说纷纭,java,php都在争吵不休,就跟别说已开始就压根没打算MVC的ASP.NET。在大家被微软用CodeBehind和CodeBeside忽悠过去N多年之后,当大家在对WebForm审美疲劳后,MVC就跟李宇春一般另类且充满吸引力。最近的新闻是微软也要在ASP.NET中推出MVC了。对于很多M饭来说是一个十分值的庆祝的事情。顺带着MonoRail也鸡犬升天,关注的人越来越多。WebForm未死,MVC却活过来了。

所以这就是我不得不来发表对MVC一下看法的原因。

上帝说“你应该了解真相,真相使你自由”

什么是MVC的真相呢?我想从来源说起

话说N多年前,在一个叫SmartTalk的国度出现了一个叫MVC的家伙,后来流窜到了java国,在Java国里呼风唤雨(java的很多有界面的组件,比如swing都是采用MVC模式设计的)。

这个MVC是个什么样的家伙?

首先,此人长了三只手。一只叫Model,它负责业务领域状态的知识,一只叫View,负责业务领域的表示视图,一只叫Controller,负责控制用户输入的流和状态。当模型某一部分发生变化的时候,通常使用事件通知表单来通知视图。但是这个家伙在Web上操作的时候遇到了麻烦。因为Web的浏览器是没有状态的,所以模型没有办法通知视图发生变化,而必须通过用户发出另一次请求才能知道模型的改变。(以上内容源自《jakarta struts编程》一书)

所以这个家伙就将我迷惑住了,如果用户需要请求两次,那么整个过程的入口在那里?View还是Control?

在微软忽悠的MVP中,其实aspx文件和aspx.cs都被混成了一个类,那么这个所谓的PageController和View(aspx页面)是耦合起来的。

反过来看java的MVC,在jsp2.0规范中,不允许直接请求jsp页面而是需要通过Servlet来重定向,具体的效果先不说,起码倒是把Controller和View分开了,而且也统一了入口,都是从控制器进入的,那么控制器的职责也就很清晰了:

  1. 拦截http请求
  2. 将请求转换成要执行的具体业务逻辑的操作
  3. 判断调用业务操作还是委托给处理程序
  4. 帮组用户选择要显示给客户端的下一个视图
  5. 将视图返回给客户端

如果按照ASP.NET的WebForm来实现的话,那么4,5两步就很让人迷惑了,因为Controller和视图已经牢牢的绑定在了一起,如何选择,如果将请求转发,那么应该也将请求转发给了下一个控制器而不是视图。

所以微软用一个MVP来忽悠了之后,大家反而迷惑了。所以新人注意了,如果你开始学WebForm就千万不要看MVC,否则也会被忽悠。

至于微软新出的MVC,没用过,不做评论。

这里我总结一下我的观点,什么样的框架算是MVC呢?

首先,M、V、C三部分的功能应该符合

Model,负责业务领域状态的知识

View,负责业务领域的表示视图

Controller,负责控制用户输入的流和状态

由于Web下的限制,Controller应该作为整个请求的入口,由Controller来组织业务逻辑(判断请求和业务逻辑的对应关系,最终的实现还是Model),而模型的改变通知视图的功能也就应该由Controller来转达一次(没办法,Web的限制,由于Controller被作为了入口,那么模型通知视图变化的事件也之只能由Controller来触发,或者也可以是Controller通知视图模型变化了,然后视图到模型去取数据)。

其实从上面的分析看来,起码来说视图应该能够根据模型自己组织输出的外观而不必假手Controller,但是在ASP.NET中实际的操作看来,模型都是通过控制器在绑定数据。

之前很早就看过Henry Fan兄的Nclay,其中的MVC组件给出的例子还没好生研究,所以在这里也期待Henry兄给出自己的宝贵意见

posted on 2007-10-19 18:15  亚历山大同志  阅读(11855)  评论(32编辑  收藏  举报

导航