UniqueID和ClientID的来源
在《漫话ID》一文中，作者提出了一个问题：为什么在ItemCreated事件中访问ClientID会导致MyButton无法响应事件，事实上 MyButton无法响应事件是因为他在客户端的ID被改变了，而此文从UniqueID和ClientID入手，进行较为深入的探讨，展示 UniqueID和ClientID是如何生成的，在何时生成，并同时解答《漫话ID》一文中作者的疑问。
为什么有UniqueID和ClientID
这个我想多数使用WebForm的人已经知道了，很大原因上是因为WebForm中存在着数据绑定控件以及自定义控件、View控件之类可以拥有子控件的控件，这就导致在控件树中很有可能存在着2个ID完全相同的对象，但是由于HTML并不允许ID的重复，于是WebForm发明出了一个叫NamingContainer的东西，并给控件提供了UniqueID和ClientID这两个属性，用于区分彼此。
虽然这两个属性经常给我们惹来这样那样的麻烦，但从总体上来说，这是一个良好的设计，无可厚非。
UniqueID和ClientID如何计算
首先需要明白的一点是，在WebForm中所有的控件最终形成一个树，每个控件是树中的一个节点。
在树型的结构中，每一个节点都拥有0个或1个父节点，而UniqueID和ClientID正是基于“从树的根部到当前节点的路径”来计算UniqueID的，我们看一下以下的示例：
<asp:Repeater ID="MyRepeater" runat="server">
<ItemTemplate>
<asp:Button ID="MyButton" runat="server" Text="My Button" />ItemTemplate>
asp:Repeater>
我们在MyRepeater中放置了MyButton，而这样简单的内容生成出的这个MyButton的最终HTML如下：
请注意看，按钮的ID变为了MyRepeater_ctl00_MyButton，Name则变为了MyRepeater$ctl00$MyButton，根据《漫话ID》一文中所述，这个ID正好是服务器端控件的ClientID，而Name又正好是服务器端控件的UniqueID。
我们现在要探索的，是为什么ID会变成这个样子，因此我们先从字面上进行理解，不能看出：
- 在这个ID中，有“MyRepeater”字样，而这正是MyButton的父节点元素Repeater的服务器端ID
- 中间有“ctl00”字样，根据我们编程的习惯，ctl应该表示着control的意思，而00自然就是索引了，这里正好表示“此MyButton是Repeater产生的列表中的第1个元素（下标为0）”
- 最后有“MyButton”字样，正好是MyButton的服务器端ID
好了，将ID分解以后我们就能非常清晰地理解ClientID的生成策略了：
生成ClientID的方法是，在控件本身的ID前加上此控件在数据绑定（如果有）中的索引再加上父控件的ClientID
那么这是怎么做到的呢，这里就提出了NamingContainer的概念，对于NamingContainer，只需要实现一个标记接口INamingContainer。
当控件在计算ClientID时，会查找当前控件的NamingContainer属性是否为null，如果不是则调用该NamingContainer的一个叫GetUniqueIDPrefix的方法，当然这个方法是递归的，在方法体内又会去调用另一个GetUniqueIDPrefix方法。
至于NamingContainer这个属性是怎么来的，事实上是在调用Controls.Add方法时加上去的，大家可以使用反编译看一下Control类一个叫AddedControl方法的实现，在此就不作赘述。