闲话Web编程模型：WebForm、MVP还是MVC？

本文主要是介绍闲话Web编程模型：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的感觉。