ASP.NET控件 - 理解ID生成

引言

任何阅读这篇文章的人都应该至少看过一次包含简单DataGrid或UserControl的HTML页面源码，并注意到'id'和'name'属性的长度。本文的目的在于理解它们有时为什么会如此之长。

背景

这些属性总是唯一的，因此说它们是控件服务器端属性UniqueID的可视面貌，并不令人惊讶。

Control类是所有WebControl类的基类，并提供了三个ID属性

• ID - 可以由程序员设置。
• UniqueID - 一个生成的只读ID，用于服务器端和postdata管理。此属性渲染'name'属性。
• ClientID - 一个特殊的只读转换的UniqueID，仅用于客户端。此属性渲染'id'属性。

对Control代码的系统分析表明，ClientID值是UniqueID值的转换，而后者是其NamingContainer.ID和自身ID的组合。

属性之间的这种关系表明，可以通过简单地操作所有相关控件的服务器端ID属性来管理'id'和'name'属性。

潜在问题

我们应该记住，几乎所有企业级ASP.NET解决方案都需要高度的定制，因此有相当数量的复合自定义控件。这些自定义控件被大量使用，并显著增加父级层次的深度。此外，我们不能忘记

• 命名业务实体并不像那样简单；
• 一个完全描述预期功能的名称将大大提高代码的可读性和可维护性（我们是否准备好为此付出代价，仅仅为了缩小页面大小？）；
• 程序员惊人的命名创造力.