ASP.NET 控件 - 客户端和服务器端的桥梁

引言

在我的上一篇文章中，我讨论了属性 'name' 和 'ID' 的长度，以及为什么它们的大小会很容易增长。在本文中，我将重点关注回答“它们为什么被渲染，以及它们在 ASP.NET 中的作用是什么？”。

背景

就属性 'ID' 而言，它的作用结束于客户端，即，此属性仅供浏览器引擎和程序员使用，以便在页面中轻松找到 HTML 元素。这个非常有用的属性并非总是必需的，因此，仅当程序员显式设置 ASP.NET 控件的 ID 属性值时，它才会被渲染。

如果你经常使用客户端脚本，那么你肯定会想过为什么这个属性并非总是被渲染。好吧，试着想想相反的情况，即所有 HTML 元素都有它们自己的 ID 属性被渲染，即使是那些通常不会被脚本更改的元素（如 Label）以及其他在你的情况下不需要的元素。在我看来，这种情况是对资源的浪费，特别是对宝贵的资源，比如网络带宽。

属性 'name' 的作用要复杂得多。事实上，ASP.NET 用户体验的大部分丰富性都建立在其独特性之上。与 'ID' 不同的是，'name' 属性几乎总是被渲染，即使它没有直接渲染到元素属性中，它仍然可以在脚本语句中使用（通常在流行的 __doPostBack 中）。'name' 属性有两个任务要完成

1. 第一个来自旧的 ASP 时代，是 'name' 值被用作服务器端集合（HttpContext.Current.Request.Form）中 POST 值的键。
2. 第二个，是 ASP.NET 增加的新职责，是将识别当前回发元素源的责任委托给 'name' 值。

这最后一种责任给 'name' 属性值添加了一个新的约束：它必须是唯一的，但它也必须能直接映射到单个服务器端控件，也就是之前渲染 'name' 属性值的那个控件。

为了完成这项任务，每个 ASP.NET 控件都有一个 UniqueID 属性，该属性基于控件层次结构构建。为了确保一个控件始终具有相同的 UniqueID，假定其父级层次结构始终以相同的方式构建；即使是动态控件，也应始终在 页面生命周期的同一位置添加。

结论

正如我在上一篇文章中展示的那样，有时 'name' 和 'id' 属性的增长超出了我们的预期，我们需要考虑减小它们的大小。任何尝试都应始终保留 'name' 的第二个责任。如果没有做到这一点，那么你将失去 ASP.NET 的一个主要好处

客户端和服务器端之间的桥梁，它允许引发服务器端控件事件，例如 OnClick 和 OnChange (OnTextChange, OnSelectIndexChange 等)。