asp.net的用户控件做得很好，再加上 metaBuilder的masterPage支持，就更好了，
这是UI方面的。
对于数据，能否跟这个控件的机制结合在一起呢。
一般的思路是从外层控件将数据一直传到需要数据的最内层控件，这不失为最强的控制模式，
但也造成了内层控件对于外层控件的过度依赖，不利于重用，
考虑masterPage的模式，则我们也可以使用类似的模式，
比如：
A控件包含B控件，B包含C控件，C控件又包含了D控件，而D控件需要一张付款单数据，
恰好A就做了这个事情，它持有一张付款单对象的实例。那么最直接的思路就是D公开一个
属性，让逐级设定这个对象。
我倒是有个反方控制的思路，即A声明一个接口，如，即付款单供应者。那么如果D必须要
付款单数据才有意义的话，它就可以往控件的外层查询这个接口，这个查询操作可以封装起来，
比如 Control.Parent is Type 等等。
这样的好处是对于数据来说，增加了灵活性，即控件不要求容器去为它主动做什么事情，它
主动去找容器的接口，一个容器增加新的控件的时候，如果设计上的接口能够满足控件的
要求，UI上放进去就是了，不需要特别照顾控件的情绪，万一搞错了，一跑起来就会报错：
“控件XX要求其容器必须实现IYYY接口”。
当然，可以实现多层的接口查找。
简而言之，通过这个方式使 UI的树结构同数据的树结构关联起来。
另外一个问题，控制流怎么办。我想到一个主意，就是任务注册查询，就像政府要求某些企业
做什么事情一样，会有一个机构，登记有谁谁谁该做些什么事情，企业嘛，自己查去。
比如说A现在在进行一个控制流环节，我们预先在某个地方维护一个注册表，哪些类型（或者再次使用接口概念）的控件可以参与到这个环节中去。 那么在 控件的IPostBackDataHandler 中就可以查询这个注册表，看看自己是不是应该参加到这种控制环节中去。
最理想的状态就是，政府想到要某些企业集资，就发个通知到工商局，到企业的某个活动点的时候，要查一下工商局，是不是现在要做某些事情了，当然了，工商局会告知企业，你的公司太小，我们需要的是大公司参与的活动，你歇着吧，于是企业就在 IPostBackDataHandler.LoadPostData 方法中返回 false.
痴人说梦，仅此而已。