Question

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

Answer 1

本文题目是乱取的，吸引眼球而已。 MVC是一个非常有争议性的话题，首先，什么算是MVC，没有一个统一的说法，众说纷纭，java,php都在争吵不休，就跟别说已开始就压根没打算MVC的ASP.NET。在大家被微软用CodeBehind和CodeBeside忽悠过去N多年之后，当大家在对WebForm审美疲劳后，MVC就跟李宇春一般另类且充满吸引力。最近的新闻是微软也要在ASP.NET中推出MVC了。对于很多M饭来说是一个十分值的庆祝的事情。顺带着MonoRail也鸡犬升天，关注的人越来越多。WebForm未死，MVC却活过来了。 所以这就是我不得不来发表对MVC一下看法的原因。 上帝说“你应该了解真相，真相使你自由” 话说N多年前，在一个叫SmartTalk的国度出现了一个叫MVC的家伙，后来流窜到了java国，在Java国里呼风唤雨(java的很多有界面的组件，比如swing都是采用MVC模式设计的)。 首先，此人长了三只手。一只叫Model，它负责业务领域状态的知识，一只叫View，负责业务领域的表示视图，一只叫Controller，负责控制用户输入的流和状态。当模型某一部分发生变化的时候，通常使用事件通知表单来通知视图。但是这个家伙在Web上操作的时候遇到了麻烦。因为Web的浏览器是没有状态的，所以模型没有办法通知视图发生变化，而必须通过用户发出另一次请求才能知道模型的改变。(以上内容源自《jakarta struts编程》一书) 在微软忽悠的MVP中，其实aspx文件和aspx.cs都被混成了一个类，那么这个所谓的PageController和View(aspx页面)是耦合起来的。 反过来看java的MVC，在jsp2.0规范中，不允许直接请求jsp页面而是需要通过Servlet来重定向，具体的效果先不说，起码倒是把Controller和View分开了，而且也统一了入口，都是从控制器进入的，那么控制器的职责也就很清晰了： 拦截http请求 将请求转换成要执行的具体业务逻辑的操作 判断调用业务操作还是委托给处理程序 帮组用户选择要显示给客户端的下一个视图 将视图返回给客户端 所以微软用一个MVP来忽悠了之后，大家反而迷惑了。所以新人注意了，如果你开始学WebForm就千万不要看MVC，否则也会被忽悠。 至于微软新出的MVC，没用过，不做评论。 首先，M、V、C三部分的功能应该符合 Model，负责业务领域状态的知识 View，负责业务领域的表示视图 Controller，负责控制用户输入的流和状态 由于Web下的限制，Controller应该作为整个请求的入口，由Controller来组织业务逻辑(判断请求和业务逻辑的对应关系，最终的实现还是Model)，而模型的改变通知视图的功能也就应该由Controller来转达一次(没办法，Web的限制，由于Controller被作为了入口，那么模型通知视图变化的事件也之只能由Controller来触发，或者也可以是Controller通知视图模型变化了，然后视图到模型去取数据)。 其实从上面的分析看来，起码来说视图应该能够根据模型自己组织输出的外观而不必假手Controller，但是在ASP.NET中实际的操作看来，模型都是通过控制器在绑定数据。