混乱的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兄给出自己的宝贵意见