ASP.NET's MVC is what a joke!

很早前还在毁人不倦的时候就在怀疑MVC模式了,因为一向对这种从CS结构里生搬硬套来的模式心存不爽。
什么是MVC模式不必赘述,相信很多TX都能随口道来一大篇,但是我们仔细想想这种在CS模型下百试不爽的最佳实践在Web里仍然是最佳的么?
熟悉Web的工作原理的人都知道,Web应用是标准的Request-Response的方式在运作,所有的请求都是在浏览器发出,服务器相应浏览器的请求,运算,得出结果,生成结果的页面,返回给浏览器。但是,绝对不可能的是在浏览器没有发起任何请求的情况下,服务器就把页面送过去了(过去有push技术,但是现在很长时间没人提起了)。而MVC模式的在这样子的工作环境下就不能采用推的技术,而必须在页面有所请求的时候才能知道视图的模型改变了,然后重绘视图,而根本不是当模型改变的时候能够主动地通知所有的视图,所以如果强用MVC模型来设计的话就成了:

视图发出请求给控制器-〉控制其根据请求操作数据->控制器获取数据填充模型->控制器选择视图用模型填充之->显示视图

这样子的过程和MVC模式的最佳实践的差距就不用多说了
我们来看看经典MVC的过程

Event(事件)导致Controller改变Model或View,或者同时改变两者。只要Controller改变了Models的数据或者属性,所有依赖的View都会自动更新。似的,只要Controller改变了View,View会从潜在的Model中获取数据来刷新自己。

这里我们可以看到区别:经典的MVC是用事件来自动驱动的,而Web的运作是过程化的,线性化的,所以我在使用MVC的时候才会感到无比的别扭。
很多时候MVC的一些其它好处,比如可以将逻辑和界面分离(Struts的确做到了而且还不错),所以很多人对这种生搬硬套的做法视而不见,所以个人以为,MVC并不是Web下的最佳实践,我们还能找到更好的方式,可能有的Framework已经在尝试有所改变,不过名字还是没改,还是叫MVC
----------------------------------------------------------------------
下面来说ASP.NET,ASP.NET实现了事件驱动的Web编程模型,本来是一个在Web上实现MVC的很好的契机,不过微软在设计的时候有不少的缺憾,并没有提出清晰的定义,2.0的时候有个MVP的提法,不过也没有在设计上就定义得很明确(微软的特点就是现有产品后有理论)。一般来说都把ASPX页面当作视图,页面的.CS文件作为控制器,视图要么类似javabean的类要么就是DataSet(其实DataSet是好东西,我最喜欢的就是它)。其实这里我觉得用UserControl作为视图更加的合理一些(我一般都是这么做的)。这里通过事件来把这些串起来。不过在事件的设置上我认为微软至少有几点是没有设置妥当的,一个是button事件的发生在PageLoad之后,按照逻辑来说,Button在点击后应该触发Button事件的代码来处理数据的工作来改变模型,之后所有的视图才可能获取更新后的模型去刷新界面,这里把Load事件放在Button事件之前在逻辑上是说不通的,当然可以认为PageLoad是用来在页面初始化的时候做一些处理,但是既然页面已经保持了状态为什么在点击按钮后还是会重新Load呢?起码之前和学生解释这个问题的时候会话大半天的工夫耐心的讲解Web的起源什么的,如果既然要标榜事件化的页面编程,就做彻底一点,把底层全部屏蔽,这里留下一个trigger让我们来踩地雷说明设计上在一开始就没有想清楚,我看要么就把pageload的功能更加单一化,只在页面第一次打开的时候执行,在有Postback的时候就不触发了,免得还要自己用个if去做个复杂的结构,很多时候在PageLoad里面要写个很复杂的结构去区分各种情况,害得我都搞不清楚是在OO还是在写意大利面条。

不敢说精通MVC,只是对自己的理解提出看法,欢迎精通MVC的大虾来批判我。

起了个很骇人的tital其实是在发牢骚,最近在用Karrigell,发现里面根本不用去关心什么request的问题,所有post的东西都直接成了变量,直接就是方法的参数,还可以通过重载方法的形式来handle具有多种参数组合的情况,想必在ASP.NET下写出来意大利面条难免牢骚更多。不过追求完美的想法是没错的,希望在3.0的时候能看到更加完美的ASP.NET。

posted on 2007-03-08 13:43  亚历山大同志  阅读(4720)  评论(28编辑  收藏

导航