混乱的MVC，.NET非要MVC不可么？

　　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分开了，而且也统一了入口，都是从控制器进入的，那么控制器的职责也就很清晰了：

　　拦截http请求

　　将请求转换成要执行的具体业务逻辑的操作

　　判断调用业务操作还是委托给处理程序

　　帮组用户选择要显示给客户端的下一个视图

　　将视图返回给客户端

　　如果按照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兄给出自己的宝贵意见。

查看本文来源