【IT168评论】学习一个新语言或者是新架构是需要时间的，我们需要摒弃原来学习的很深入并且用的很熟练的架构来迎合新架构嘛?是的，如果让我说，我的回答是否，但是我需要看清这个新架构究竟和原来的架构有哪些改进，是否真的需要我们投入大量的时间去学习?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的原因，但是是原因之一，虽然这个原因可能会有点牵强。