ASP.NET中的蝴蝶效应

cat_hsfz 2006-11-11 09:12:12
ASP.NET中本来应该每个控件对自己内部的逻辑负责,尽量少依赖环境,对环境产生影响时尽量请求上级控件负责统一操作,理论上来说能够达到很好的解耦效果。然而实际上这东西有时候竟然存在蝴蝶效应,也就是对一个控件的一点点小改动会导致控件外大面积的影响。

《ASP.NET - 解决一个大难题的同时引入另一个更大的难题》,这篇文章是由于昨天遇到了上述的蝴蝶效应问题而写在自己的blog里面的,现在转过来让大家讨论下。如果你是控件设计师,可以说说在设计控件时如何避免这类问题,如何通过测试来找出这类问题;如果你是控件使用者,可以说说碰到这类问题时如何发现、解决或者绕过去。

----------------------------------------------------------------
原文地址如下,如需再次转载请保留作者与原文地址信息:
http://www.cnblogs.com/cathsfz/archive/2006/11/11/557257.html
----------------------------------------------------------------

以下为原文全文转载:
----------------------------------------------------------------
前言

ASP.NET的优点我说过很多次了,也就是各个控件独立负责自己内部的逻辑,这是一个好事情,因为它解决了原本ASP处理逻辑耦合度高的问题。然而这是需要代价的,那就是引入ASP.NET页面生命周期,随着控件的多层嵌套,应用的复杂度增加,我们再次陷入泥潭!

问题

其实这个文章题目我两个月前就写下了,可是一直没想写完它,直到今天我在这个泥潭中泡了几个小时,于是决定先从泥潭中跳出来把文章写完,再跳进去继续解决问题。问题是这样的:

使用MS AJAX 1.0 Beta2 + 2.0 CTP新建一个项目,同时在Bin中放上Beta2的AjaxControlToolkit.dll。
扔上一个Accordion,放置几个AccordionPane,设置一下CssClass。
在Page_Load中使用Page.LoadControl加载一个UserControl,然后添加到页面上。
接着发现UserControl内的控件无法正常触发事件,陷入泥潭中……
首先要说明,如果仅仅做第3步那个UserControl肯定正常运作,那意味着问题出在ScriptManager或Accordion中出现了问题。

正文

想知道到底是什么出问题了吗?先听我说说这个ASP.NET页面生命周期的问题吧。

由于生命周期按阶段划分,任务在不同阶段按部就班完成,所以我们的每一个操作都是阶段相关的,有些操作仅能在特定的阶段操作,有些操作在不同阶段执行会导致不同的结果。当然,MS希望尽量消除这些阶段间的差异,例如让一个操作在尽可能多的阶段中都能执行,并且尽可能减少在不同阶段中操作引发的不同结果。然而这不可能完全做到,例如我们都知道ViewState读写限制为仅能在某些阶段进行,于是依赖于ViewState的控件属性也就因此受到同样的限制。

控件属性读写受阶段限制,这很好接受,对吧?因为这仅仅是一层依赖关系。顺着依赖关系推广出去,情况会变得越来越复杂,限制的原因埋藏得越来越底层,接着我们发现复杂性这一问题在ASP.NET这种结构良好的体系中出现了,而消灭这种复杂性的银弹还没被发明。

作为控件或组件的开发人员,我们当然有义务消除阶段差异,让下游的开发人员面对更低的复杂性,而且我们也确实尽力去做了。控件的每一层封装,都包含着这种努力,并向上承诺尽可能低的阶段差异。然而为了让控件看起来简单易用,我们不可能将这些差异完整地记录在文档之中,我们尝试去隐瞒细节,控件被层层封装时我们都这样做。底层文档没告诉我的差异,我当然也没必要写到这一层的文档上去;底层文档提及了的差异,我尽力弥补了,即使弥补得不太好,也不写到这一层的文档上去。于是文档就好像神话传说一样随着世代相传而改变,最终没有人知道这个控件依赖于某些底层的阶段差异。

做过控件开发的人都知道,有时候我们必须根据实际情况采用不同的方式构建看起来一样的控件。例如最简单的数据控件都会存在是否PostBack的构建差异,如果是非PostBack,则需要在DataBind时构建并将数据保存到ViewState,如果是PostBack则根据ViewState直接构建,如果PostBack后又遇到了DataBind则需要清除原来的构建并重新根据新数据构建。再复杂一些的控件,还会分步骤构建,默认情况下为了消除使用方的阶段差异,部分构建步骤会尽可能靠前到Init时执行,而另外一部分构建步骤则尽可能推迟到PreRender时执行,中间部分则尽可能减少自己的变化以便使用方操作。然而事情不会那么简单,使用方的某些操作(通常是访问某个属性)如果依赖于某个构建步骤的完成,因此一旦这些操作出现,原本在PreRender才执行的特定构建步骤就要提前执行,当这样的操作在不同阶段进行多几次,构建步骤就已经散落在页面生命周期的各阶段。

构建步骤可能散落于页面生命周期的各阶段对于控件设计师来说是一个严峻的问题,这意味着他要保证任何一个构建步骤在任何一个阶段执行都是无差异的,当然这不可能做到,于是又要引入别的机制来减少这种差异,复杂性就此产生了,接下来随着复杂性的增加控件设计师越来越无法确保较低的阶段差异程度,这就到控件使用者遭殃了,如果控件使用者又再把控件封装,并且依然企图降低阶段差异程度,那么灾难也就发生了……

结果

我花了几个小时在泥潭中泡了几个小时,边泡边写这篇文章,问题当然已经有结果了。

如果Accordion设置了HeaderCssClass或者ContentCssClass,那就会出问题,但如果为AccordionPane都加上以上两个属性,又不会有问题了。这样的情况当然通过用Reflector查看这两个类的代码来解决,结果发现Accordion会检测每一个AccordionPane是否有设置这两个属性,如果没有就把AccordionPane的设置为和自己的一样。在AccordionPane被设置时,会调用this.EnsureChildControls(),这是一个会导致构建步骤提前执行的方法,于是控件构建的顺序就改变了,不仅仅Accordion内部的顺序改变了,整个Page的都改变了。由于控件的ID是按顺序自动分配的,包括我那个UserControl,构建顺序的改变意味着ID的改变,也就相当于整个控件树都改变了,事件当然不能正常触发。

最后的解决方案当然是为我那个UserControl指定ID。我花了那么多个小时才发现自己做了件蠢事,一早打开Trace来看控件树就应该能发觉UniqueID的变化。

总结

虽然这个问题看起来不是一个太好的例子,因为一打开Trace就应该能找到问题的来源,但实际上它却正好揭示了ASP.NET框架内部的“蝴蝶效应(Butterfly Effect)”——随着复杂度的增加,任何一个细微的改变都会导致全局上的巨大变化。在设计ASP.NET的时候,MS可能也在想着解耦,在简单的情况下这东西确实也解耦,然而在复杂的情况下却正好背道而驰,这真的是很讽刺。
----------------------------------------------------------------
...全文
3465 78 打赏 收藏 转发到动态 举报
写回复
用AI写文章
78 条回复
切换为时间正序
请发表友善的回复…
发表回复
cooolchen 2007-02-22
  • 打赏
  • 举报
回复
看了,不懂,以后再看.
seaer06 2007-02-22
  • 打赏
  • 举报
回复
学习

rola 2007-02-22
  • 打赏
  • 举报
回复
关注,学习
winner2050 2007-02-22
  • 打赏
  • 举报
回复
看了几行!

太长了,没有心思看了。
Student02370236 2007-02-22
  • 打赏
  • 举报
回复
收藏,几天后我可能会开始这方面的工作,可以留意一下这个问题
LifeForCode 2007-02-22
  • 打赏
  • 举报
回复
james_hunter 2007-02-15
  • 打赏
  • 举报
回复
严重赞同
sp1234(到底是谁把软件加价五倍?)
james_hunter 2007-02-15
  • 打赏
  • 举报
回复
楼主的问题是自己造成的…为UserControl解决ClientId应该是一个commonsense.
如此一个在最底层的严重的问题,最后被放大出来,更严重也不为过了。
mostice 2007-02-15
  • 打赏
  • 举报
回复
认真看了3遍,虽然不能全部理解。
但牵一发而动全身的感受还是有的。
大飞飞虫 2007-02-15
  • 打赏
  • 举报
回复
我尽量不使用第三方控件,尽量使用MS原配的,毕竟严格测试才会封到一起,最近做的项目就是基于ICALLBACKHANDLE的接口自己开发的AJAX,这样稳定一些。
jxf654 2007-02-15
  • 打赏
  • 举报
回复
up
lxwin01 2007-02-15
  • 打赏
  • 举报
回复
意见与sp1234相符.
ztwz 2007-02-14
  • 打赏
  • 举报
回复
看不懂.mark一下,等看得懂又来.
flyingfz 2007-02-14
  • 打赏
  • 举报
回复
mark
yyf863000 2007-02-14
  • 打赏
  • 举报
回复
看不懂
IQuestionHandler 2007-02-14
  • 打赏
  • 举报
回复
不错
ParadiseX 2006-11-14
  • 打赏
  • 举报
回复
虽然不是很懂,但是觉得挺有意思的 ————《食神》
jedliu 2006-11-14
  • 打赏
  • 举报
回复
顶!
xray2005 2006-11-14
  • 打赏
  • 举报
回复
学习ing .........
yuanzhaojun 2006-11-14
  • 打赏
  • 举报
回复
加载更多回复(58)

62,046

社区成员

发帖
与我相关
我的任务
社区描述
.NET技术交流专区
javascript云原生 企业社区
社区管理员
  • ASP.NET
  • .Net开发者社区
  • R小R
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

.NET 社区是一个围绕开源 .NET 的开放、热情、创新、包容的技术社区。社区致力于为广大 .NET 爱好者提供一个良好的知识共享、协同互助的 .NET 技术交流环境。我们尊重不同意见,支持健康理性的辩论和互动,反对歧视和攻击。

希望和大家一起共同营造一个活跃、友好的社区氛围。

试试用AI创作助手写篇文章吧