2008年3月微软针对ASP.NET 3.5发布的MVC框架（Preview 2 版本)是一个真正意义上的ASP.NET MVC框架。至今，短短4个月内此框架已经发展到Preview 4版本。许多国内外业界人士称该框架为其前基于Web表单开发模式的历史性“颠覆”。本文站在对ASP.NET MVC框架与传统ASP.NET Web表单开发模式进行简明理论对比的角度对ASP.NET MVC框架的发展前景作出初步展望。
一、引言
一直以来，软件架构师们在开发软件的方法及架构方面争论不休。这样的一些典型的例子包括针对ORM与存储过程、REST与SOAP结构的讨论，等等。最近一段时间，在微软社区内又展开了一场有关ASP.NET Web表单与ASP.NET MVC框架的讨论。许多人认为ASP.NET MVC框架最后将会取代Web表单机制，而也有一些人坚持认为ASP.NET MVC框架未来不可能取代如今已经牢牢占据.NET平台上ASP.NET开发统治地拉的Web表单技术。那么，究竟ASP.NET MVC框架是否会取代Webforms呢？
值得注意的是，从一开始，微软的众多权威人士都一致表示：ASP.NET MVC框架仅仅将作为Web表单方案的一种可能的替代方案，而不会彻底取代它，而Web表单也不可能取代ASP.NET MVC。因此，真正的发展趋势将是：ASP.NET MVC与Web表单将共同存在，ASP.NET MVC决不会成为Web表单的取代者。所以，如果你比较喜欢ASP.NET MVC，你可以选择使用它；而如果你感到Web表单更易于上手，你也可以尽情地按照你的传统方式继续使用它。也就是说，两种途径都只是针对不同的选择、不同的方法而已，而提供给开发者不同的选择本身是一件好事，仅此而已。当然，不同的选择也完全可以应用于其他的平台，特别是另一块比较火的Java开发平台。
二、ASP.NET Web表单方案存在的问题
ASP.NET Web表单方案存在哪些方面的不足呢？Web表单的指导思想是把Windows桌面应用中的表单模型引入到Web应用程序的开发中。这种模型很快就吸引了大批的传统Windows桌面应用开发程序员，特别是以前的VB 6.0程序员。今天，许多VB 6.0开发者已经转到了ASP.NET Web开发领域，但是他们并没有基本的HTTP与Web基本知识。为了模拟传统型Windows桌面应用程序中的表单开发体验，Web表单引入了事件驱动的方法，而且还引入了Viewstate和Postback等相关概念。最终，Web表单技术知彻底地攻克了Web中无状态特征这个难关。随之而来的是，Viewstate和Postback带来了大量的问题，从而提高了Web应用程序开发的复杂性。例如，即使一些非常简单的Web页面也有可能产生大于100KB尺寸的Viewstate，这当然会在某些情况下严重影响系统的性能。此外，开发人员还无法控制Web表单生成的HTML；而且，ASP.NET服务器控件生成的HTML既混杂有内联方式也包含不符合标准的过时的标签。Web表单所带来的另一个问题是，与JavaScript框架的集成比较困难，这主要是因为生成的HTML的命名惯例所造成的。此外，Web表单相应的页面生命周期太复杂了，在整个ASP.NET框架中所有内容都是紧耦合型的并且仅使用一个类来负责显示输出和处理用户输入。因而，单元测试几乎是一项不可能的任务。而我们都知道，在现代软件开发中，特别是当我们遵循敏捷软件方法论及相应惯例开发软件时，单元测试是很重要的。既然Web是无状态的，那么，Postbacks和Viewstate就不会完美的解决方案。
三、ASP.NET MVC架构所具有的特征
ASP.NET MVC架构能够简化ASP.NET Web表单方案编程中存在的复杂部分，但是在威力与灵活性方面将一点也不会逊色于后者。ASP.NET MVC架构要实现的在Web应用程序开发中引入模型-视图-控制器（即“Model-View-Controller”）UI模式，此模式将有助于开发人员最大限度地以松耦合方式开发自己的程序。MVC模式把应用程序分成三个部分—模型部分，视图部分以及控制器部分。其中，视图部分负责生成应用程序的用户接口；也就是说，它仅仅是填充有自控制器部分传递而来的应用程序数据的HTML模板。模型部分则负责实现应用程序的数据逻辑，它所描述的是应用程序（它使用视图部分来生成相应的用户接口部分）的业务对象。最后，控制器部分对应一组处理函数，由控制器来响应用户的输入与交互情况。也就是说，Web请求都将由控制器来处理，控制器会决定使用哪些模型以及生成哪些视图。正如读者所猜想到的，MVC模型将使用其特定的控制器动作（Action）来代替Web表单事件。因此，使用MVC模型的主要优点在于，它能够更清晰地分离关注点,更便于进行单元测试，从而能够更好地控制URL和HTML内容。值得注意的是，MVC模型不使用Viewstate、Postback、服务器控件以及基于服务器技术的表单，因而能够使开发人员全面地控制视图部分所生成的HTML内容。MVC模型使用了基于REST（Representational state transfer）的URL来取代Web表单模型中所使用的文件名扩展方法，从而可以使我们构造出更为符合搜索引擎优化(SEO)标准的URL。当前，MVC仅仅支持.Net框架3.5版本。因此，如果你想要在.Net框架2.0下使用MVC的话，我建议你访问一下Scott Hanselman的撰写的博客文章（Deploying ASP.NET MVC on ASP.NET 2.0），你会从中找到相应的答案。
在本短文中，我并不是展示一个具体的MVC示例应用程序（因为一个简单的示例剖析就会占去相当的篇幅）。因此，关于MVC框架的具体实例，读者可以参考微软最权威专家Scott Guthrie的博客，也可以参考我发表在IT168中的几篇博文
（http://space.itpub.net/?uid-14466241-action-viewspace-itemid-344617）。
四、结论
选择将根据不同的人而有所不同。如果你想要更多控制HTML你想要进行测试驱动开发的话，或者你更关注Web标准，可访问性，或者你想构建SEO友好的URL，那么你可以选择MVC模型。如果你想要实现对系统的更好的控制以及想实现面向状态的事件驱动的Web开发的话，你可以选择Web表单模型。如果你感到使用MVC更舒适些，请选择这种模型好了；而如果你感到使用Web表单模型更舒适些，就应该毫不犹豫地选择使用Web表单模型。两者仅仅是选择的不同。如果你刚开始使用ASP.NET Web表单踏上你的职业生涯而还没有对Web有一个全面的了解，那么，你一下转到MVC模型方面肯定存在不少的困难。
较之于Web表单，我更为喜欢MVC模型，而且我感觉微软在今后更有可能朝着MVC作了更多的努力。这种模型所具有的技术特征以及开源天性深深地吸引了我。此外，MVC模型还允许我全面地控制HTML并且支持测试驱动开发（TDD）。还有，在MVC模式下，我们可以非常容易地集成进jQuery以及其他JavaScript开发框架。借助于C# 3.0中新引入的扩展方法，我们自己可以构造功能强大的丰富的帮助类。
一、引言
一直以来，软件架构师们在开发软件的方法及架构方面争论不休。这样的一些典型的例子包括针对ORM与存储过程、REST与SOAP结构的讨论，等等。最近一段时间，在微软社区内又展开了一场有关ASP.NET Web表单与ASP.NET MVC框架的讨论。许多人认为ASP.NET MVC框架最后将会取代Web表单机制，而也有一些人坚持认为ASP.NET MVC框架未来不可能取代如今已经牢牢占据.NET平台上ASP.NET开发统治地拉的Web表单技术。那么，究竟ASP.NET MVC框架是否会取代Webforms呢？
值得注意的是，从一开始，微软的众多权威人士都一致表示：ASP.NET MVC框架仅仅将作为Web表单方案的一种可能的替代方案，而不会彻底取代它，而Web表单也不可能取代ASP.NET MVC。因此，真正的发展趋势将是：ASP.NET MVC与Web表单将共同存在，ASP.NET MVC决不会成为Web表单的取代者。所以，如果你比较喜欢ASP.NET MVC，你可以选择使用它；而如果你感到Web表单更易于上手，你也可以尽情地按照你的传统方式继续使用它。也就是说，两种途径都只是针对不同的选择、不同的方法而已，而提供给开发者不同的选择本身是一件好事，仅此而已。当然，不同的选择也完全可以应用于其他的平台，特别是另一块比较火的Java开发平台。
二、ASP.NET Web表单方案存在的问题
ASP.NET Web表单方案存在哪些方面的不足呢？Web表单的指导思想是把Windows桌面应用中的表单模型引入到Web应用程序的开发中。这种模型很快就吸引了大批的传统Windows桌面应用开发程序员，特别是以前的VB 6.0程序员。今天，许多VB 6.0开发者已经转到了ASP.NET Web开发领域，但是他们并没有基本的HTTP与Web基本知识。为了模拟传统型Windows桌面应用程序中的表单开发体验，Web表单引入了事件驱动的方法，而且还引入了Viewstate和Postback等相关概念。最终，Web表单技术知彻底地攻克了Web中无状态特征这个难关。随之而来的是，Viewstate和Postback带来了大量的问题，从而提高了Web应用程序开发的复杂性。例如，即使一些非常简单的Web页面也有可能产生大于100KB尺寸的Viewstate，这当然会在某些情况下严重影响系统的性能。此外，开发人员还无法控制Web表单生成的HTML；而且，ASP.NET服务器控件生成的HTML既混杂有内联方式也包含不符合标准的过时的标签。Web表单所带来的另一个问题是，与JavaScript框架的集成比较困难，这主要是因为生成的HTML的命名惯例所造成的。此外，Web表单相应的页面生命周期太复杂了，在整个ASP.NET框架中所有内容都是紧耦合型的并且仅使用一个类来负责显示输出和处理用户输入。因而，单元测试几乎是一项不可能的任务。而我们都知道，在现代软件开发中，特别是当我们遵循敏捷软件方法论及相应惯例开发软件时，单元测试是很重要的。既然Web是无状态的，那么，Postbacks和Viewstate就不会完美的解决方案。
三、ASP.NET MVC架构所具有的特征
ASP.NET MVC架构能够简化ASP.NET Web表单方案编程中存在的复杂部分，但是在威力与灵活性方面将一点也不会逊色于后者。ASP.NET MVC架构要实现的在Web应用程序开发中引入模型-视图-控制器（即“Model-View-Controller”）UI模式，此模式将有助于开发人员最大限度地以松耦合方式开发自己的程序。MVC模式把应用程序分成三个部分—模型部分，视图部分以及控制器部分。其中，视图部分负责生成应用程序的用户接口；也就是说，它仅仅是填充有自控制器部分传递而来的应用程序数据的HTML模板。模型部分则负责实现应用程序的数据逻辑，它所描述的是应用程序（它使用视图部分来生成相应的用户接口部分）的业务对象。最后，控制器部分对应一组处理函数，由控制器来响应用户的输入与交互情况。也就是说，Web请求都将由控制器来处理，控制器会决定使用哪些模型以及生成哪些视图。正如读者所猜想到的，MVC模型将使用其特定的控制器动作（Action）来代替Web表单事件。因此，使用MVC模型的主要优点在于，它能够更清晰地分离关注点,更便于进行单元测试，从而能够更好地控制URL和HTML内容。值得注意的是，MVC模型不使用Viewstate、Postback、服务器控件以及基于服务器技术的表单，因而能够使开发人员全面地控制视图部分所生成的HTML内容。MVC模型使用了基于REST（Representational state transfer）的URL来取代Web表单模型中所使用的文件名扩展方法，从而可以使我们构造出更为符合搜索引擎优化(SEO)标准的URL。当前，MVC仅仅支持.Net框架3.5版本。因此，如果你想要在.Net框架2.0下使用MVC的话，我建议你访问一下Scott Hanselman的撰写的博客文章（Deploying ASP.NET MVC on ASP.NET 2.0），你会从中找到相应的答案。
在本短文中，我并不是展示一个具体的MVC示例应用程序（因为一个简单的示例剖析就会占去相当的篇幅）。因此，关于MVC框架的具体实例，读者可以参考微软最权威专家Scott Guthrie的博客，也可以参考我发表在IT168中的几篇博文
（http://space.itpub.net/?uid-14466241-action-viewspace-itemid-344617）。
四、结论
选择将根据不同的人而有所不同。如果你想要更多控制HTML你想要进行测试驱动开发的话，或者你更关注Web标准，可访问性，或者你想构建SEO友好的URL，那么你可以选择MVC模型。如果你想要实现对系统的更好的控制以及想实现面向状态的事件驱动的Web开发的话，你可以选择Web表单模型。如果你感到使用MVC更舒适些，请选择这种模型好了；而如果你感到使用Web表单模型更舒适些，就应该毫不犹豫地选择使用Web表单模型。两者仅仅是选择的不同。如果你刚开始使用ASP.NET Web表单踏上你的职业生涯而还没有对Web有一个全面的了解，那么，你一下转到MVC模型方面肯定存在不少的困难。
较之于Web表单，我更为喜欢MVC模型，而且我感觉微软在今后更有可能朝着MVC作了更多的努力。这种模型所具有的技术特征以及开源天性深深地吸引了我。此外，MVC模型还允许我全面地控制HTML并且支持测试驱动开发（TDD）。还有，在MVC模式下，我们可以非常容易地集成进jQuery以及其他JavaScript开发框架。借助于C# 3.0中新引入的扩展方法，我们自己可以构造功能强大的丰富的帮助类。