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方面的。
对于数据，能否跟这个控件的机制结合在一起呢。
一般的思路是从外层控件将数据一直传到需要数据的最内层控件，这不失为最强的控制模式，
但也造成了内层控件对于外层控件的过度依赖，不利于重用，
考虑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.
痴人说梦，仅此而已。