浅谈ASP.NET页面生命周期(控件)
ASP.NET的优点我说过很多次了，也就是各个控件独立负责自己内部的逻辑，这是一个好事情，因为它解决了原本ASP处理逻辑耦合度高的问题。然而这是需要代价的，那就是引入ASP.NET页面生命周期，随着控件的多层嵌套，应用的复杂度增加，我们再次陷入泥潭！
其实这个文章题目我两个月前就写下了，可是一直没想写完它，直到今天我在这个泥潭中泡了几个小时，于是决定先从泥潭中跳出来把文章写完，再跳进去继续解决问题。问题是这样的：
1. 使用MS AJAX 1.0 Beta2 + 2.0 CTP新建一个项目，同时在Bin中放上Beta2的AjaxControlToolkit.dll。
2. 扔上一个Accordion，放置几个AccordionPane，设置一下CssClass。
3. 在Page_Load中使用Page.LoadControl加载一个UserControl，然后添加到页面上。
4. 接着发现UserControl内的控件无法正常触发事件，陷入泥潭中……
首先要说明，如果仅仅做第3步那个UserControl肯定正常运作，那意味着问题出在ScriptManager或Accordion中出现了问题。
想知道到底是什么出问题了吗？先听我说说这个ASP.NET页面生命周期的问题吧。
由于ASP.NET页面生命周期按阶段划分，任务在不同阶段按部就班完成，所以我们的每一个操作都是阶段相关的，有些操作仅能在特定的阶段操作，有些操作在不同阶段执行会导致不同的结果。当然，MS希望尽量消除这些阶段间的差异，例如让一个操作在尽可能多的阶段中都能执行，并且尽可能减少在不同阶段中操作引发的不同结果。然而这不可能完全做到，例如我们都知道ViewState读写限制为仅能在某些阶段进行，于是依赖于ViewState的控件属性也就因此受到同样的限制。
控件属性读写受阶段限制，这很好接受，对吧？因为这仅仅是一层依赖关系。顺着依赖关系推广出去，情况会变得越来越复杂，限制的原因埋藏得越来越底层，接着我们发现复杂性这一问题在ASP.NET这种结构良好的体系中出现了，而消灭这种复杂性的银弹还没被发明。
作为控件或组件的开发人员，我们当然有义务消除阶段差异，让下游的开发人员面对更低的复杂性，而且我们也确实尽力去做了。控件的每一层封装，都包含着这种努力，并向上承诺尽可能低的阶段差异。然而为了让控件看起来简单易用，我们不可能将这些差异完整地记录在文档之中，我们尝试去隐瞒细节，控件被层层封装时我们都这样做。底层文档没告诉我的差异，我当然也没必要写到这一层的文档上去；底层文档提及了的差异，我尽力弥补了，即使弥补得不太好，也不写到这一层的文档
相关文档：
五种常见的ASP.NET安全缺陷
2004-10-18 19:30作者：menhal 出处：动态网制作指南责任编辑：方舟
保证应用程序的安全应当从编写第一行代码的时候开始做起，原因很简单，随着应用规模的发展，修补安全漏洞所需的代价也随之快速增长。根据IBM的系统科学协会（Systems Sciences Institute）的研究，如果等到软件部署之后� ......
问题提出:
在应用程序中经常需要查询数据。当查询结果数据量比较大的时候，检索结果、界面显示都需要花费大量的时间。为了避免这个问题，应该每次只检索部分数据，也就是使用常见的分页方式来处理。分页的问题在asp.net中好像非常简单，只要在GridView中启用分页就可以了。启用分页后，GridView关联数据源控件，依旧会加载 ......
1. C#语言方面
1.1 垃圾回收
垃圾回收解放了手工管理对象的工作，提高了程序的健壮性，但副作用就是程序代码可能对于对象创建变得随意。
1.1.1 避免不必要的对象创建
由于垃圾回收的代价较高，所以C#程序开发要遵循的一个基本原则就是避免不必要的对象创建。以下列举一些常见的情形。
1.1.1.1 避免循环创建对� ......
验证控件用于验证用户的输入，利用这些控件，开发人员可以轻松的实现对用户输入的验证。ASP.NET提供了六种验证控件。
1.Required Field Validator：验证输入是否为空的控件。
主要属性：
Control To Validate：表示要进行检查的控件ID。此属性必须设置为输入控件的ID，否则会发生异常。另外该ID所代表的控件� ......
关于页面传值的方法，引发了很多讨论。看来有很多人关注这个，我就我个人观点做了些总结，希望对大家有所帮助。
1. 使用QueryString变量
QueryString是一种非常简单的传值方式，他可以将传送的值显示在浏览器的地址栏中。如果是传递一个或多个安全性要求不高或是结构简单的数值时，可以使用这个方法。但是对于传� ......
