asp.net编程模式:WebForm、MVP还是MVC？

此文写给所有还在迷茫中的初学者并欢迎高手进来讨论。
首先什么是Web编程模型？在这里我们定义Web编程模型为如何编写代码生成html返回给最终用户的方法。它包括两部分，一个是如何编写Web应用程序 的规范，另一个则是实现这一规范的Web编程框架，而ASP.NET就是用来实现WebForm模型的框架，当然ASP.NET的功能比较强大，留下了足 够的空间，足够我们在此基础之上实现另外的模型，比如MonoRails。换个比方，和ASP.NET比较类似的，Jsp，Servlet也是实现Web 编程模型的基础结构，Sun所定义的Jsp2.0规范定义了一个如何编写Web应用程序的规范，当然你可能不喜欢这么做，那么你还可以使用Struts或 者SpringMVC，不过换汤不换药，之不过是换了一种做法而已。
WebForm其实是一个很好的Idear。在我才接触WebForm编程的时候，当时的感触是原来Web下还能这么写程序。在WebForm模型下，我 们将整个浏览器当成一个窗体来进行编程，把页面上的元素都作为控件来操作，拖放式，基于事件，不再是面条式的流程控制，一切都是那么的美好。但是很快的， 随着使用WebForm开发的项目数量越来越多，就越来越感觉到其中的弊端，其实罪过不在WebForm，而是在于微软，把这么好的概念给糟蹋了。
WebForm的原罪：
其一：控件管得太宽，滥用Html样式：
所有的控件都通过Html样式管理自己的外观，结果就算增加了Css属性，但是Vs在编辑控件的时候随便点一点就自作主张的给你加上了 Html样式，很多时候还会很恶心的给你加上<font>标记，结果美工做得好好的Html代码在Vs里很快就变得面目全非，很多对Html 熟悉的程序员就直接在Html视图编辑代码，结果WebForm 的所见即所得和拖放的特性就又丧失了。这一点在很注重外观输出的网站项目中很突出，结果是本来能够提高效率的特性反而降低了效率。就算是在企业内部系统， 领导要看的也是外观，所以这一点是我极其厌恶的，自从2003以来就这样了，而多年来微软依然故我，完全没有改变。
其二：事件驱动，却不彻底，结果造成初学者理解困难，而代码也很丑陋
主要指的就是那个很不清晰的Page_Load事件，玩过WinForm下编程的都知道，窗体确实有一个Load事件，但是微软在处理 Page_Load的时候有一个很重要缺点，既然费了老大的力，用ViewState，不惜牺牲性能也要在WebForm下保证页面看起来是保持了状态 的，也就是说在离开这个页面前，这个页面是要保持状态的，那么在离开这个页面之前，这个页面就只能Load一次，但是在微软的WebForm下却每一次都 要Load页面，所以很多从Winform转过来的程序员在这里就迷惑了。在之前的很多同学的Post里都对这一点表示过不满。但是看起来6年过去，微软 仍然没有打算改正这一点，却去费力的推MVP还弄了个MVC什么的。其实把这一点改正了，我都愿意给WebForm加分。
其三：页面的表现和事件的逻辑混淆在一个类中。
其实也就是aspx页面和aspx.cs文件的关系问题，这一点微软在推MVP的时候其实也就是在这一点上做出了改进。不过.cs文件到 底是处理表示逻辑还是处理什么其实大多数人都是迷糊。而且据某人的Post里说新加坡的某大牛宣称.CS就是控制器，Ok，就这点来说都是很混乱了，既然 混乱，说明这里也是个问题。
我们该怎么办？其实很简单两个字：凉拌。既然微软已经这么做了，而我们靠ASP.NET吃饭的，如果要使用WebForm模式来编程，那么我们也 只有认命，然后改变可以改变的，克服不可改变的。框架的限制并不是我们不能完成项目的接口，而其他很多因素都比这一点更能影响项目的完成。所以与其费力在 这一点上批评微软，不如在项目管理上多花点功夫来得要紧。
MVP由于是在WebForm的基础上改进出来的，我也使用很少，就留给有深入了解的大牛来解释了，我在这里只有一点粗略的了解，就是MVP大约 用来改进aspx和.cs耦合的问题，也就是WebForm的一个改进版，不过没有编辑器的支持，而且一二两点问题也没有克服。一个子：唉！
最后是MVC，其实MVC比起WebForm来更加的古老，作为一个种设计模式来说，其实把MVC应用于Web编程来说确实是老师傅遇到了新问 题。首先是Web环境是属于一种瘦客户端的环境，所以在表示层：Html的能力其实很弱，只有get，post等有限的几种方法，而且只能够使用拉的方 式，也就是每一次数据的更新都是通过浏览器主动发出请求而开始的，而经典的MVC模型所要求的当模型发生变化的时候通知视图刷新界面其实就成了 mission imposiable，那么现在在Web上的MVC框架其实都是经典MVC的变种，或者有人称之为InputController，不过将表示，控制，模 型分离开的思想其实是没有错的。也可以说在Web下的MVC其实也就是另外一种思考的模式而已，既然思考的方式不同，那么要在WebForm下混合MVC 也就成了不可能的任务。很多人这么做的目的，也不过是既不想放弃方便的WebForm，有想要在设计上有清晰的代码模型。虽然个人并不看好，但是但愿能有 人成功吧。
总的来说WebForm和MVC不过是一种选择而已，既然选择了其中一种，也就是说路只有一条，改变可以改变的，接受不能改变的。或许有人想也许 路不止这两条，而ASP.NET也留给了我们足够的自由度去实现我们所认定的不同的Web编程方式。但是其实结果都是一样，如果真的是百花齐放，结果可能 和python下的Web框架一样变得无从选择。而至于MonoRails，嗯，个人来说不是很喜欢，由于在公司我并不负责具体项目的编程任务所以我也不 大喜欢一些一揽子解决方案，什么都要负责，但是却存在了过大的学习负担，MonoRails对我来说太重了，很多时候我们只是需要一把起子的时候却递给你 了一把瑞士军刀。
最后，正如怪怪所说，WebForm和MVC的争论其实大可不必，不是一路的何必强求，与其争论如何选择，不如多花点时间在项目管理上，说不定收到的效果然而更好。多优化优化项目的管理，早点下班休息，多点时间回家陪陪父母，多点时间学习新东西，这才是正道啊。
By the way，在java里也不是MVC一统天下。感兴趣的可以去看看Apache下的Tapestry项目，感觉很类似WebForm了的事件驱动了，不过实现上区别还是很大。而上次在谈金蝶的Opramask的时候也是感觉有些类似WebForm的感觉。

http://www.cnblogs.com/Alexander-Lee/archive/2007/10/22/933027.html