轉(zhuǎn)：http://www.cnblogs.com/GrayZhang/archive/2009/03/05/how-uniqueid-is-generated.html

在《漫話ID》一文中，作者提出了一個(gè)問題：為什么在ItemCreated事件中訪問ClientID會導(dǎo)致MyButton無法響應(yīng)事件，事實(shí)上 MyButton無法響應(yīng)事件是因?yàn)樗诳蛻舳说腎D被改變了，而此文從UniqueID和ClientID入手，進(jìn)行較為深入的探討，展示 UniqueID和ClientID是如何生成的，在何時(shí)生成，并同時(shí)解答《漫話ID》一文中作者的疑問。

為什么有UniqueID和ClientID

這個(gè)我想多數(shù)使用WebForm的人已經(jīng)知道了，很大原因上是因?yàn)閃ebForm中存在著數(shù)據(jù)綁定控件以及自定義控件、View控件之類可以擁有子 控件的控件，這就導(dǎo)致在控件樹中很有可能存在著2個(gè)ID完全相同的對象，但是由于HTML并不允許ID的重復(fù)，于是WebForm發(fā)明出了一個(gè)叫 NamingContainer的東西，并給控件提供了UniqueID和ClientID這兩個(gè)屬性，用于區(qū)分彼此。

雖然這兩個(gè)屬性經(jīng)常給我們?nèi)莵磉@樣那樣的麻煩，但從總體上來說，這是一個(gè)良好的設(shè)計(jì)，無可厚非。

UniqueID和ClientID如何計(jì)算

首先需要明白的一點(diǎn)是，在WebForm中所有的控件最終形成一個(gè)樹，每個(gè)控件是樹中的一個(gè)節(jié)點(diǎn)。

在樹型的結(jié)構(gòu)中，每一個(gè)節(jié)點(diǎn)都擁有0個(gè)或1個(gè)父節(jié)點(diǎn)，而UniqueID和ClientID正是基于“從樹的根部到當(dāng)前節(jié)點(diǎn)的路徑”來計(jì)算UniqueID的，我們看一下以下的示例：

<asp:Repeater ID="MyRepeater" runat="server">
<ItemTemplate>
<asp:Button ID="MyButton" runat="server" Text="My Button" /></ItemTemplate>
</asp:Repeater>

我們在MyRepeater中放置了MyButton，而這樣簡單的內(nèi)容生成出的這個(gè)MyButton的最終HTML如下：

<input id="MyRepeater_ctl00_MyButton" type="submit" value="My Button" name="MyRepeater$ctl00$MyButton"/>

請注意看，按鈕的ID變?yōu)榱薓yRepeater_ctl00_MyButton，Name則變?yōu)榱?MyRepeater$ctl00$MyButton，根據(jù)《漫話ID》一文中所述，這個(gè)ID正好是服務(wù)器端控件的ClientID，而Name又正好是 服務(wù)器端控件的UniqueID。
我們現(xiàn)在要探索的，是為什么ID會變成這個(gè)樣子，因此我們先從字面上進(jìn)行理解，不能看出：

在這個(gè)ID中，有“MyRepeater”字樣，而這正是MyButton的父節(jié)點(diǎn)元素Repeater的服務(wù)器端ID

中間有“ctl00”字樣，根據(jù)我們編程的習(xí)慣，ctl應(yīng)該表示著control的意思，而00自然就是索引了，這里正好表示“此MyButton是Repeater產(chǎn)生的列表中的第1個(gè)元素（下標(biāo)為0）”

最后有“MyButton”字樣，正好是MyButton的服務(wù)器端ID

好了，將ID分解以后我們就能非常清晰地理解ClientID的生成策略了：

生成ClientID的方法是，在控件本身的ID前加上此控件在數(shù)據(jù)綁定（如果有）中的索引再加上父控件的ClientID

那么這是怎么做到的呢，這里就提出了NamingContainer的概念，對于NamingContainer，只需要實(shí)現(xiàn)一個(gè)標(biāo)記接口INamingContainer。
當(dāng) 控件在計(jì)算ClientID時(shí)，會查找當(dāng)前控件的NamingContainer屬性是否為null，如果不是則調(diào)用該NamingContainer的 一個(gè)叫GetUniqueIDPrefix的方法，當(dāng)然這個(gè)方法是遞歸的，在方法體內(nèi)又會去調(diào)用另一個(gè)GetUniqueIDPrefix方法。
至于NamingContainer這個(gè)屬性是怎么來的，事實(shí)上是在調(diào)用Controls.Add方法時(shí)加上去的，大家可以使用反編譯看一下Control類一個(gè)叫AddedControl方法的實(shí)現(xiàn)，在此就不作贅述。

回到問題

現(xiàn)在我們回到《漫話ID》一文中的問題，為什么在DataGrid控件的ItemCreated事件中去調(diào)用ClientID會影響以后的執(zhí)行。

我想令作者感到困惑的是，他僅僅獲取了ClientID，而沒有對其作任何的修改。作者認(rèn)為他并沒有影響到Button的狀態(tài)，因此Button應(yīng)當(dāng)按其正常的方式進(jìn)行渲染。

在這里就不得不說一個(gè)問題，非常多的人認(rèn)為屬性這東西的讀取僅僅是一個(gè)簡單的return，他們沒有想到在屬性的get體中可以進(jìn)行非常多的邏輯， 而這些邏輯又很有可能影響到對象的狀態(tài)，而我想正是這種“想當(dāng)然”致使作者沒有仔細(xì)地去看ClientID的get過程中，Button到底發(fā)生了什么。 那么就由我來大致地梳理一下這個(gè)思路吧。

首先我反編譯了ClientID屬性，可以看到他的get體的內(nèi)容，其代碼如下：

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遠(yuǎn)不止return this._clientID;這么簡單，事實(shí)是，控件根本不保存當(dāng)前的ClientID，而是在每一次獲取時(shí)都從UniqueID去計(jì)算，并將UniqueID中的分隔符（也就是$）替換為下劃線（_）并返回。

再仔細(xì)地看代碼，我們會發(fā)現(xiàn)首先調(diào)用了EnsureID方法，這就像我們在自定義控件的時(shí)候會調(diào)用EnsureChildControls方法一 個(gè)，EnsureID會檢測當(dāng)前控件的ID是否已經(jīng)生成，如果沒有生成則會使用一定的策略進(jìn)行生成，下面就是EnsureID方法的代碼：

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

我們看到，在EnsureID方法中就用到了NamingContainer，當(dāng)且僅當(dāng)NamingContainer不為null的時(shí)候，該方法才有作用。
什么嘛，結(jié)果在EnsureID方法中根本就沒有涉及到UnqiueID的計(jì)算問題，呵呵是不是有被騙的感覺？
但是這么一來，又是什么影響著ClientID呢，再仔細(xì)地回看ClientID的get方法體，最后也只能說是UniqueID這個(gè)屬性在搞鬼了。
對，UniqueID和ClientID一樣，并不是一個(gè)簡單的屬性，他在get體內(nèi)也包含了大量的邏輯，以下就是這些邏輯：

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;
}
}

我想代碼已經(jīng)非常清楚了，如果NamingContainer為null，則UniqueID只會返回當(dāng)前控件的ID，否則將會通過NamingContainer的GetUniqueIDPrefix方法去計(jì)算本文一開始說的那種格式的ID并返回。
好了，至此我們已經(jīng)把ClientID的生成過程分析清楚了，這里總結(jié)一下：

ClientID是由UniqueID經(jīng)過簡單的字符串替換形成的

UniqueID是通過NamingContainer形成的

看到這里我想《漫話ID》一文的作者已經(jīng)明白了吧，為什么在ItemCreated事件中訪問ClientID會導(dǎo)致最終HTML頁面上的2個(gè) Button都叫“MyButton”，如果還不明白，請去斷點(diǎn)調(diào)試ItemCreated事件，看看MyButton的NamingContainer 是什么。
呵呵，你以為MyButton的NamingContainer是null？那么你肯定沒調(diào)試過哦~~

在ItemCreated事件中，MyButton的NamingContainer是DataGridItem，但問題在于DataGridItem此時(shí)并沒有加入到DataGrid中（在ItemDataBound事件中才被加入到DataGrid中），因此DataGridItem的NamingContainer是null。
而DataGridItem的GetUniqueIDPrefix方法則需要知道自己在DataGrid中的索引，以便返回類似ctl00這樣的格式，既然沒有加入到DataGrid中，DataGridItem就只能返回一個(gè)空字符串。
MyButton將DataGridItem返回的空字符串和自己的ID一拼接，就形成了UniqueID，此時(shí)的UniqueID正好是自己的ID。
并且MyButton又將這個(gè)UniqueID給保存了起來，在今后的訪問中不會再一次重新計(jì)算，于是這個(gè)不規(guī)范的UniqueID也將一直被使用到成為HTML。

總結(jié)

發(fā)現(xiàn)自己的表達(dá)能力實(shí)在很差，不知道有沒有將這個(gè)問題說清楚，總之：

對ClientID屬性的訪問將直接導(dǎo)致控件計(jì)算UniqueID

在不恰當(dāng)?shù)臅r(shí)候計(jì)算UniqueID，將可能導(dǎo)致錯(cuò)誤的結(jié)果

要保證控件與當(dāng)前頁面的控件樹的根連通的情況下才訪問ClientID

.NET中有很多屬性并不是簡單的return，他們會改變對象的狀態(tài)，往往這就是解決問題的切入點(diǎn)

轉(zhuǎn)載于:https://www.cnblogs.com/Unrmk-LingXing/p/4110803.html

總結(jié)

以上是生活随笔為你收集整理的转：UniqueID和ClientID的来源的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。