为什么要从Webform过渡到MVC中

可以说，在未来几年中，Web form的使用会逐渐减少，而取而代之的就是MVC。可能你不会同意我的观点，那么我就试着阐述一下我的观点，如果你还是不能接受，那么请你反驳我。

学习一个新语言或者是新架构是需要时间的，我们需要摒弃原来学习的很深入并且用的很熟练的架构来迎合新架构嘛？是的，如果让我说，我的回答是否，但是我需要看清这个新架构究竟和原来的架构有哪些改进，是否真的需要我们投入大量的时间去学习？Mvc 是一种架构模式，它带来了全新的和asp时代同样的开发体验（注：我不是说这是倒退）。

下面我就来阐述一下对于Web form，MVC是否值得我们去学习。

1.View State

相信大家对于这个视图状态都很熟悉，它是用来保存我们在页面中输入的数据状态，以便我们可以在刷新页面或者回发时使页面回到我们原来的输入数据时的状态，这个效果很好的实现了我们的需求。但是同时，我们要问自己一下，是否我们就真的需要这些，需要页面刷新时显示原来的数据，这是否是有意义的？

还有就是View State在web form时代大行其道，在每个页面都会存在，甚至在复杂的页面中他的大小甚至很大，在每次 页面回发时都会传递View State状态，我们不说服务器解析这些View State需要时间，就是每次页面传输都要传递这些View State就会使带宽增加，显示网页的时间变长。这在2.0时代，最起码是我所不允许的。

2.Page Life Cycle 页面生命周期

在Web form中存在着复杂的生命周期，我甚至清楚的记得在我学习Web form的时候，都是拿着笔在纸上画着这些周期图，在每个周期页面会执行什么动作。这就像我在学习c#连接数据库的时候写sql helper，让我很头疼。例如在Page_render()中不应该访问具体的控件，因为这时控件还没有生成（有园友提出错误，我查阅了资料也认为这是错误的，因为这时已经把控件渲染要输出，特此声明。感谢园友提出错误，我会积极改正），如果要访问请在Page_load()中，我们每天都要和Page_Load()事件打交道，至少我很经常。IsPostBack是经常可以见到的方法。

如果你觉得你可以完全掌握这些生命周期，那么至少你是一名大牛。如果你可以很随意的就控制页面的生命周期，并且控制控件的生成，那么我会很敬仰你。

3.False sense of concerns 失败的关注点分离

现在我们做软件，讲究的都是可维护性、可重用性以及关注点分离。何为关注点分离，我的理解就是每层结构只负责他自己的事情，不属于他的不能控制，也不要试图控制。例如，我们在code behind中写了访问数据库的代码，调用了sql helper中的类，但是现在是数据库服务器的服务没有开启，那么这次调用肯定会抛出异常。难道让我们在code behind中处理这些异常，那么我们程序员会累死的，异常应该是sql helper中处理，而不是code behind。这应该就是所谓的关注点分离。还有就是关注点分离应该是每个类只负责他自己的工作，而不要在一个类Sql Helper中有着返回html的语句出现。

4.Limited control over HTML 对于html的控制极差

我在页面生命周期中说了，如果你可以随意的更改生成的控件，那么我会崇拜你。如果说对于一个服务器端控件可以控制生成html的样式，或者生成html的ID、name，以便可以让js使用，这是很困难的。当然在.net 4.0中添加了一个属性，那就是ClientIDMode,如果把这个属性值设置为static，就可以生成和定义的ID一样的html的ID值。默认情况下这是不被启用的，会生成复杂的、嵌套的ID值。这对于我们在客户端操作html标签是很困难的。

当然了，这不是你可以转向MVC的原因，但是是原因之一，虽然这个原因可能会有点牵强。

5.Leaky abstraction 脆弱的抽象

Web form试图隐藏所有的http状态（http的无记忆性或者是无状态性）。我们在拖入一个服务器控件的时候从来需要考虑他会在什么时候显示？因为服务器控件已经实现了这些，例如，IsPostBack 方法为什么可以用来判断页面是否回发，它的实现原理是什么？我们不会关心，我们只关心这个方法能够完成什么，这就够了？真的够了吗？

我认为没有，只是会使用，我想任何一个只要认识英文的人都可以完成，但是会使用就够了吗？性能问题达到了吗？会出现哪些问题？我们都不知道，我们只是用了一个黑盒子，但是里面是什么东西我们不知道？如果是陷阱我们也会毫不犹豫的跳进去？对吗？

偶尔的熟悉一下源码，对于提升我们自己的开发水平有帮助之外，我们也可以发现很多我们可以控制的问题，避免他们发生？所以，亲爱的朋友们，不要仅仅限于使用，有时候大牛和小牛的根本区别就是小牛不知道为什么要这样？而大牛指导如何更好的这样。

6.Low testability 极差的可测试性

我在以前开发web form的时候，采用服务器控件可以大大的提高开发速度。但是，我从来不知道如何去测试我开发的代码是否运行正常。唯一的方式就是自己一个人没事的时候点击、点击、再点击。还有就是设置断点，按住F11，不断的点击键盘，直到看到这些代码都想吐的地步？

但是在MVC中，这些问题都不再存在，因为我们可以使用Nunit等可以进行单元测试的工具，我们可以把测试精确到每一行代码，我们可以实现测试的自动化，避免了手动点击浪费的大量时间。这是一件好事，不是吗？

还有我个人认为最重要的一个原因就是，你如果有web form的开发基础，那么学习MVC可以说就是很简单的事情，因为MVC中没有了服务器控件，有的只是html标签以及一些可以生成html标签的helper类。我个人感觉做美工的如果想转开发，这倒是不错的时机，因为html对于美工来说笔程序员更熟悉。

在MVC中没有View State，可以对html进行完全的控制，可以不再使用原来的Url rewriter，而是采用MVC中自带的Route（Url路由系统），良好的关注点分离框架（Model、View、Controller），每一层都是负责自己的任务。

在MVC中不是每一个地址都会对一个一个具体的页面，你可以定义多个Action，返回同一个页面。在MVC中因为有了强大的路由系统，所以我们不会再见到www.cnblogs.com/default.aspx,这样的地址了，而是取而代之的www.cnblogs.com/home/index ,这是一个巨大的突破。可以让特定的页面具有具体的含义。这是URl友好，你认为呢？

我并不是说MVC会取代Web form，而是他们之间的对比性，当然如果可以避免一些问题的存在，那么让MVC和Web from共存在同一个项目中，或许是不一个不错的选择。但是前提还是需要你学习MVC，我个人认为在未来几年中，Web form和MVC会共存。

好了，说了这么多，我只是有一句话，就是如果你想在未来的Web开发中不落后，那么就在业余时间学习一下MVC吧。

如果你想你的网站具有更好的可维护性，那么采用MVC是你的明智之举。