关于WebForm与MVC的讨论，年初的时候已经有一段很长时间的讨论了。我无意再去争论哪种架构模式更适合我们做开发，不管是哪个领域，技术的存在都有其不同的历史意义和市场价值。我更关注的是，在合适的机会去掌握更多的技术，从技术实现的角度来寻找当前阶段最为顺手的一种做事方法。所以请注意，在这里不讨论WebForm与MVC的优劣，适用场景。在这里只有ASP.NET WebForm与ASP.NET MVC，同样属于ASP.NET框架下的两种不同的Web开发技术，是如何充分发挥ASP.NET平台的强大功能，以及对于掌握ASP.NET WebForm的开发人员，转向ASP.NET MVC架构的学习成本。这就是我本篇文章的立意所在，同时我也是希望为我之后的几篇MVC系列文章提供一些注脚和铺垫。

之前，从事ASP.NET开发，在没有特殊说明的情况下，指的就是ASP.NET WebForm的开发。之前ASP.NET技术的发展，直接就体现在WebForm技术上的进步。在ASP.NET MVC 出现之后，之前大家所掌握的ASP.NET技术对于ASP.NET MVC仍然有效，并且是最基础的部分。包括：页面处理流程，Web请求上下文对象，Web配置系统，公用性的组件模块，部分的服务器控件等等。我想从这几大块来详细阐述ASP.NET MVC对于ASP.NET技术的继承：

1. 页面处理流程：ASP.NET MVC 的页面处理流程仍然是在ASP.NET原有的处理流程上的扩展，在在上游的请求通道不变的前提下，通过特定的IHttpModule和IHttpHandler来处理ASP.NET MVC的请求。与WebForm页面处理不一样的地方就在于，在WebForm中，每一个页面都是一个IHttpHandler实例，页面的事件流程就是从IHttpHandler的ProcessRequest(HttpContext httpContext)方法开始。而在ASP.NET MVC中，所有的Controller都并不是IHttpHandler的继承实例，它的Action是在MvcHandler中被执行的，当然我们也可以自定义是MvcHandler。
2. Web请求上下文对象：在ASP.NET MVC中，处理请求的线程模型没有改变。请求的上下文对象，与原有的ASP.NET WebForm仍然是共用的。
3. Web配置系统：ASP.NET MVC仍然使用原有的配置系统，在Web.config中只是部分的配置节点不适用于ASP.NET MVC，比如页面访问授权配置。
4. 公用性的组件模块：在ASP.NET MVC中，包括Membership，healthMonitoring，httpModule,trace在内的内置和自定义的组件模块仍然是继续可用。
5. 部分服务器控件可用：首先，最为明显的是我们使用的是.aspx页面作为MVC的View。虽然后缀仍然为.aspx，但是它的意义已经不再是一个可执行的页面文件了，不再是一个纯粹意义上的IHttpHandler。但是它仍然是继承于原有的Page基类。在ASP.NET MVC中，将它作为View来展示，仍然以ProcessRequest为入口来执行页面，也就意味着除了回发事件的相关事件和函数不会被执行外，页面的执行事件流程仍然是有效的。以此，如果不考虑服务器控件的性能和其它因素影响，我们仍然是可以使用大部分的服务器控件，当然用不用取决于你。

以上是我总结到的一些ASP.NET MVC对ASP.NET原有技术的继承，但是做为ASP.NET技术的发展，有很多东西是本身就是乏善可陈的，不说，也应该知道就是那样。但是说出来，更有助于大家来区分ASP.NET，(ASP.NET)WebForm，ASP.NET MVC(为什么WebForm前面的ASP.NET加括弧呢？大家来说说原因)这三者的概念区别和关系。

下面我还想来说说，ASP.NET MVC较之前的ASP.NET(WebForm)开发技术在实践上有哪些比较明显的区别：

1. .aspx文件，已经不再是一个可被独立请求的页面了。你不能对它从物理上进行权限控制。
2. 我们的少用服务器控件了。我们仍然可以使用，你完全可以不考虑runat='server'的性能影响。但是并不保证所有的服务器控件都可用。可能还有其它的原因让你选择不使用服务器控件。
3. 我们没有PostBack和页面回发事件机制了。提交表单我们基本使用Web的原生方式了，传输的数据量也更为合理。
4. 我们少用ViewState了。少用，意味着我们还是可以用的。只是由于MVC架构的限制，我们在ViewState存的值并不会被序列化到客户端去，它有效性是在一次请求的上下文中。在某些特定的场合内，ViewState还是能发挥它的余热，并且并不影响性能。
5. 要处理一个用户的自定义请求，比如RSS请求。我们不再需要定义一个IHttpHandler或特定的.aspx页面。处理用户的每个请求都只是在一个Controller的Action函数当中，在Action函数中，你可以输出View，可以输出JSON字符串，还可以输出任何自定义格式的文件和输出流。
6. 业务逻辑与UI逻辑从架构上得到了很好的分离，但是你要不想这么做，仍然也是有效的。只是在这种情况下，你还是选择WebForm吧。

ASP.NET MVC和WebForm在很多实现上的统一，是我们已经掌握ASP.NET原有开发模式的开发人员顺利的上手MVC保证。之后陆续会有几篇我在用MVC实践自己一个网站后，对MVC的一些总结和心得。