关于PostBack，我曾经也写过一篇博客《深入理解 __doPostBack》。在这篇文章里有对PostBack进行了一些研究，现在看来研究的还是不够深入。不过从原理上来说，ASP.NET WebForm中的一般WEB控件（为什么是一般呢？因为如Button等少数控件不是调用__doPostBack方法的）在向服务器回发请求时，调用的就是__doPostBack方法，通过表单提交的方式来向服务器提交请求。而WebForm所提供的WEB事件模型也是以__doPostBack这个方法为基础的，往服务器传送的两个隐含变量（__EVENTTARGET，__EVENTARGUMENT）就是PostBack事件分发的根据。__EVENTTARGET保存着向服务器发出PostBack请求的控件ID，ASP.NET根据这个ID就可以找到它所对象的服务器端控件的实例。__EVENTARGUMENT保存的是当前PostBack的一些参数。除此之外，PostBack还需要什么条件呢？
在前段时间关于WebForm和MVC的讨论中，有人提到禁用了ViewState，也就无法使用了PostBack。这也给我提了一个醒，确实ViewState与PostBack有非常紧密的关系，在大多数情况下，如果控件的状态是动态维护的。比如说DropDownList的Items是通过下面的代码添加的：
1: protected void Page_Load(object sender, EventArgs e)
2: {3: if (!this.IsPostBack)
4: {5: DropDownList1.Items.Add(new ListItem("1", "Value1"));
6: DropDownList1.Items.Add(new ListItem("2", "Value2"));
7: } 8: }而不是在HTML页面上静态添加（或是在OnInit事件之前添加，不能加IsPostBack的判断），这时，如果禁用ViewState，那么DropDownList的SelectedIndexChanged事件将不会被正常触发，并且DropDownList的Item项将会被清空。所以从这个角度来说，如果要使用PostBack，那么ViewState势必不能被禁用。
除此之外，PostBack还有一些不足：
1）页面在PostBack后，刷新页面时会出现非常不好的用户体验。
2）搜索引擎的不友好。
3）在编写服务器端代码时要特别的小心，特别是对IsPostBack的判断。
尽管PostBack在WebForm的事件机制占有举足轻重的地位，它出现极大的方便了我们以事件驱动方式来开发WEB应用。从短期的入门应用中确实有它重要的意义。但从现实出发，还是必须得根据不同的应用场合有先择性的使用。在网站前台型应用中，应该消灭一切可以消灭的PostBack。因为做为前台，它的作用就是展示还有查询。而如果对查询，分页等操作使用PostBack的话，一方面搜索引擎的不友好，另一方面给大多数用户带来非常不好的用户体验，增加了整个页面的请求时间。同时，它们所传的参数又非常有限，这情况下就需要使用链接的方式来传参。
对于应用型的后台开发，由于在提交数据时可能会有比较多的表单数据。这时，这时结合DetailView或FormView，使用PostBack来提交数据又可以给我们带来非常大的方便，这种情况下我们不禁用ViewState也没有关系，ViewState并不会很大，而至于刷新的问题，我们可以使用UpdatePanel来帮助解决。但是如果对于浏览数据仍然是要特别注意，特别是有GridView的页面进行PostBack数据查询，分页时，尽量都能改成链接的方式来实现。
总体来说，PostBack的使用还是要特别注意，能少用就少用，但有时用它确实也会给我们带来非常大的方便。对于应用型的后台开发，如果使用EXT的话，那么就是可以完全摒弃WebForm，或MVC了。因为它有自己一整套完整的开发流程，从目前来看，确实是一种全新的体验。
连续两篇讨论的PostBack和ViewState，可能结论都是偏向消极的。它们的存在有其重要意义的同时，难免会带来一些负面影响，但这种影响的代价在很多情况下过大而导致大多数人的反唇相讥。在软件工程中，衡量软件的标准不是越快越好，而是在用户接受的合理的时间范畴内，得到正确的结果，并且它所花费的代价（包括开发，维护，部署等成本）是最少的。我相信只要使用得当，它们还是可以充分发挥它们的作用的。
从极端的来说，去掉PostBack和ViewState后，WebForm仍然还是WebForm。它只是少了两样两把利弊同样明显的双刃剑，它余下的事件机制，组件化开发，页面模型仍然是我们进行WebForm开发最有力的武器。
