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。
什么是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。
