UniqueID和ClientID的来源

回到问题

现在我们回到《漫话ID》一文中的问题，为什么在DataGrid控件的ItemCreated事件中去调用ClientID会影响以后的执行。

我想令作者感到困惑的是，他仅仅获取了ClientID，而没有对其作任何的修改。作者认为他并没有影响到Button的状态，因此Button应当按其正常的方式进行渲染。

在这里就不得不说一个问题，非常多的人认为属性这东西的读取仅仅是一个简单的return，他们没有想到在属性的get体中可以进行非常多的逻辑，而这些逻辑又很有可能影响到对象的状态，而我想正是这种“想当然”致使作者没有仔细地去看ClientID的get过程中，Button到底发生了什么。那么就由我来大致地梳理一下这个思路吧。

首先我反编译了ClientID属性，可以看到他的get体的内容，其代码如下：

public virtual string ClientID
{
    get
    {
        this.EnsureID();
        string uniqueID = this.UniqueID;
        if ((uniqueID != null) && (uniqueID.IndexOf(this.IdSeparator) >= 0))
        {
            return uniqueID.Replace(this.IdSeparator, '_');
        }
        return uniqueID;
    }
}

可以看到，ClientID的get远不止return this._clientID;这么简单，事实是，控件根本不保存当前的ClientID，而是在每一次获取时都从UniqueID去计算，并将UniqueID中的分隔符（也就是$）替换为下划线（_）并返回。

再仔细地看代码，我们会发现首先调用了EnsureID方法，这就像我们在自定义控件的时候会调用EnsureChildControls方法一个，EnsureID会检测当前控件的ID是否已经生成，如果没有生成则会使用一定的策略进行生成，下面就是EnsureID方法的代码：

protected void EnsureID()
{
    if (this._namingContainer != null)
    {
        if (this._id == null)
        {
            this.GenerateAutomaticID();
        }
        this.flags.Set(0x800);
    }
}

我们看到，在EnsureID方法中就用到了NamingContainer，当且仅当NamingContainer不为null的时候，该方法才有作用。
什么嘛，结果在EnsureID方法中根本就没有涉及到UnqiueID的计算问题，呵呵是不是有被骗的感觉？
但是这么一来，又是什么影响着ClientID呢，再仔细地回看ClientID的get方法体，最后也只能说是UniqueID这个属性在搞鬼了。
对，UniqueID和ClientID一样，并不是一个简单的属性，他在get体内也包含了大量的逻辑，以下就是这些逻辑：

public virtual string UniqueID
{
    get
    {
        if (this._cachedUniqueID == null)
        {
            Control namingContainer = this.NamingContainer;
            if (namingContainer == null)
            {
                return this._id;
            }
            if (this._id == null)
            {
                this.GenerateAutomaticID();
            }
            if (this.Page == namingContainer)
            {
                this._cachedUniqueID = this._id;
            }
            else
            {
                string uniqueIDPrefix = namingContainer.GetUniqueIDPrefix();
                if (uniqueIDPrefix.Length == 0)
                {
                    return this._id;
                }
                this._cachedUniqueID = uniqueIDPrefix + this._id;
            }
        }
        return this._cachedUniqueID;
    }
}

我想代码已经非常清楚了，如果NamingContainer为null，则UniqueID只会返回当前控件的ID，否则将会通过NamingContainer的GetUniqueIDPrefix方法去计算本文一开始说的那种格式的ID并返回。
好了，至此我们已经把ClientID的生成过程分析清楚了，这里总结一下：

1. ClientID是由UniqueID经过简单的字符串替换形成的
2. UniqueID是通过NamingContainer形成的

看到这里我想《漫话ID》一文的作者已经明白了吧，为什么在ItemCreated事件中访问ClientID会导致最终HTML页面上的2个Button都叫“MyButton”，如果还不明白，请去断点调试ItemCreated事件，看看MyButton的NamingContainer是什么。
呵呵，你以为MyButton的NamingContainer是null？那么你肯定没调试过哦~~

在ItemCreated事件中，MyButton的NamingContainer是DataGridItem，但问题在于DataGridItem此时
并没有加入到DataGrid中（在ItemDataBound事件中才被加入到DataGrid中），因此DataGridItem的
NamingContainer是null。
而DataGridItem的GetUniqueIDPrefix方法则需要知道自己在DataGrid中的索引，以便返回类似ctl00这样的
格式，既然没有加入到DataGrid中，DataGridItem就只能返回一个空字符串。
MyButton将DataGridItem返回的空字符串和自己的ID一拼接，就形成了UniqueID，此时的UniqueID正好是
自己的ID。
并且MyButton又将这个UniqueID给保存了起来，在今后的访问中不会再一次重新计算，于是这个不规范的
UniqueID也将一直被使用到成为HTML。

总结

发现自己的表达能力实在很差，不知道有没有将这个问题说清楚，总之：

1. 对ClientID属性的访问将直接导致控件计算UniqueID
2. 在不恰当的时候计算UniqueID，将可能导致错误的结果
3. 要保证控件与当前页面的控件树的根连通的情况下才访问ClientID
4. .NET中有很多属性并不是简单的return，他们会改变对象的状态，往往这就是解决问题的切入点