ASP.NET中WebForms和MVC框架：既生瑜何生亮？(2008-07-08 18:02)

关于ASP.NET平台下的Web Forms和MVC，乍一看来，大有一种“既生瑜何生亮”的感觉，但坐下来仔细思考，还是有其各自存在的道理的。首先,我们先来看一下Web Forms, 几年的实践证明Web Forms是一个非常稳定和成熟的平台，无疑它是强大的，但也不是完美无缺的。从以下几个方面来看它的强大之处：

 

1、性能优秀

实践证明，Web Forms的性能还是不错的，即使在性能要求非常高的情况下，它也能够表现优秀。

 

2、对初学者的门槛低

微软设计了一个完整Web开发环境，使得构建Web应用有了新的体验，开发人员只需在一个可视化设计器中拖放控件、并且在表单中设置属性，然后编写代码来响应事件即可。这使得对于程序逻辑的操作变得非常直观，就好像在开发一个WinForm应用一样。从这个角度来说，从Web Froms入门Web开发是一件非常容易的事情。

 

3、可扩展性

Web Forms模型提供了一个高度抽象的框架，这个框架有着非常强大的扩展能力。即使在性能要求非常高的应用中，也不大会出现扩展方面的问题。除了ASP.NET内置的若干WEB控件外，我们可以根据需要开发并定义特定控件去完成特定任务。这一特性似的Web Forms具备了强大的扩展能力。正因为这个特性，可能ASP.NET控件厂商比其他平台下的总和还要多。

 

事情往往是这样的，缺点往往来自于它的优点，WebForms也是如此。 Web Froms对WEB开发进行了“高度抽象”后，才得以具备他的上手容易、扩展性强的特性。让开发人员能够轻松地拖放控件，并且通过响应页面和控件的各种事件来快速开发Web应用。这很不错，但是首先这种高度的抽象使很多开发人员完全忽略了在这背后HTML是如何运作的。

 

因为Web Froms利用引擎把抽象模型生成HTML代码，如果不加以优化和控制，很容易产生以下问题：

1）产生无法通过校验的HTML代码，或是非常冗余且不易管理的HTML布局；

2）产生包含大量ViewState的页面，ViewState的尺寸远远超过所需的内容，使得页面打开缓慢；

3）产生无法理解的ID值；

4）容易将业务逻辑和表现层逻辑混在一起；

 

分析以上的几个问题，究其原因是Web Forms的引擎非常复杂。由于Web开发的复杂性和状态管理的复杂性，Web Froms框架为了达到模型化开发的目的，只能对琐碎的Web开发进行高度抽象化，这既是它的成功之处，也是它的弊病之根。因为引擎给页面的执行过程带来了许多的负面效应。

 

下面我们再来看看方兴未艾的ASP.NET MVC框架吧！

MVC框架完全将WebForms的缺点抛到一边，因为它舍弃了Page类和其他相关的负担。采用了一个全新的Http Handler来实现MVC框架，所以它与Page类无关，也避免了很多Web Forms框架所带来的复杂性。MVC框架的一个关键特性是提供了创建自定义视图（View）的能力。虽然生成的视图依旧使用了ASPX页面：ViewPage类，它基于Page类，但是并不会直接被HTTP Handler执行，而是被MVC引擎用作内容生成器，这比在完整的Web Forms框架中运行传统的ASPX页面要显得轻量了许多。

 

ASP.NET MVC在工作时是通过URL Routing机制来解析URL（如 http://localhost/articles/2008/07/10/54321），并且根据URL的格式将它们引导至特定的控制器，而且这种引导机制可以很容易的进行自定义。

 

很有趣的是，正如几十年前的唐装时下又开始流行一样，几年前的WEB开发模式转了一大圈也又回来了。Web Forms模型曾经是.NET平台下Web开发最推崇的方式，MVC框架在一定程度上回到了传统的ASP风格，那便是直接使用脚本来手动生成HTML的开发方式。Web Forms还是有许多优点的，虽然微软开始尝试提供另外一种全新的选择——MVC框架，但这并不意味着我们必须完全转向它。毕竟MVC框架出现的时间还不够长，现在还不能算作久经考验。虽然MVC框架很快就吸引一批开发人员（包括本人在内），但它在灵活性、可扩展性和可用性等方面还不能与Web Forms相媲美。