众所周知在编写WebCustomControl时继承于WebControl基类的Attributes以及其AttributesCssStyle属性是十分常用和重要的但就是这两个重要的属性如果开发中使用不当却会带来莫名其妙的效率问题
由于html的灵活性和不完备性导致了WebControl基类没有完整的表现html元素所提供和支持的所有标签属性和CSS属性（当然由于不同browser的兼容问题要提供完备的属性是不可能的）又由于很多html标签属性和CSS属性都是很生僻的很少或极少被使用如果要完备的支持反而会成为WebControl的负担所以Attributes和AttributesCssStyle这两个属性很好的解决了这个问题当然这两个属性除了支持应有的html标签属性和CSS属性外还支持任何合法的自定义key/value对这里要讨论的问题就来之这个对自定义key/value对的支持上
Attributes属性的类型是一个AttributeCollection本来很自然的一个东西可是不知道怎么搞得AttributeCollection的构造函数却需要一个StateBag参数
publicAttributeCollection(StateBagbag)
{
this_bag=bag;
}
这样的结果就是Attributes和AttributesCssStyle可能会被保存在ViewState中事实上ASPNET默认确实会保存其中的内容到ViewState中
这种设计真的是让人觉得莫名其妙在大家对ViewState效率问题的讨论中觉得ViewState确实是鸡肋用来保持一些服务器状态和数据让大家觉得方便也就算了可是居然把和UI相关的内容都一股脑存到ViewState里真的是疯狂
下面是使用Attributes定义了一些自定义内容后的ViewState的情形
// AnalysisReport自定义控件上定义了一些自定的内容
Attributes和AttributesCssStyle被自动保存到ViewState中后除了ViewState体积急增后PostBack时Load ViewState的负担也同时增大了上面这个事例中的页面PostBack的LoadState代价如下图
实际上我在编写控件时从来没有想过要保持Attributes和AttributesCssStyle也没有想过要再次使用其中的数据而且这个默认保存到ViewState的行为居然不能定制（至少我还没有发现）后来想到在ASPNET页面生存期中SaveState结束在PreRender中所以在Render事件中使用Attributes和AttributesCssStyle的就不会保存到ViewState中去
修改代码
protectedoverridevoidOnPreRender(EventArgse)
{
thisAttributes[abc]=;
thisAttributesCssStyle[abcstyle]=style;
baseOnPreRender(e);
}
为如下形式
protectedoverridevoidRender(HtmlTextWriteroutput)
{
thisAttributes[abc]=;
thisAttributesCssStyle[abcstyle]=style;
outputWrite(Text);
}
就不会再将Attributes和AttributesCssStyle保存到ViewState中了上面那个AnalysisReport按上面的示例修改后绑定同样数据的运行效果为
LoadState的代价也大大降低其开销为
