今天做了一个简单的asp.net页面。
动态创建了asp:radioButton, 在Page_Load事件中，当isPostBack为false时，才去创建，结果当页面提交时(PostBack)，原来在界面显示的radioButton消失了。
初步想是VeiwState的问题。后来找KB，才知道，这种动态创建control的时候，页面提交，是需要自已写代码重新创建control tree。跟ViewState没有关系。ViewState是对control本身的状态维护，不是对control tree的状态维护。
后面用asp:RadioButtonList来代替radioButton.奖RadioButtonList静态写在aspx中。但将它的ViewState设为false. 同样在Page_Load中的IsPostBack为false时候才对RadioButtonList进行动态绑定，结果是，提交页面仍不见了radioButton。将RadioButtonList的ViewState设为True。提交页面的时候，就没有任何问题。
这里的原因是，RadioButtonList控件本身对ViewState进行了编码，它利用了ViewState来进行control tree的重建。
Reference:
Aside: What is INamingContainer?
INamingContainer is a marker interface, meaning it has no methods to implement. A control "implements" this interface to let the framework know that it plans on giving it's child controls really specific IDs. It's important to the framework, because if a two instances of the same control are on the same page, and the control gives its child controls some specific ID, there'd end up being multiple controls with the same ID on the page, which is going to cause problems. So when a Control is a naming container, the UniqueID for all controls within it will have the parent's ID as a prefix. This scopes it to that control. So while a child control might have ID "foo", its UniqueID will be "parentID$foo" (where parentID = the ID of the parent). Now even if this control exists twice on the page, everyone will still have a UniqueID.
INamingContainer also has the property that any controls within it that do not have a specific ID will have its ID automatically determined based on a counter that is scoped to it. So if there were two naming containers, foo and bar, they might have child controls with UniqueIDs foo$ctl01 and bar$ctl01. Each naming container gets its own little counter.
Note that the ID "foo$ctl01" does not necessarily imply that ctl01 is a direct child control of foo! All it means is that foo is ctl01's naming container (control.NamingContainer). It's parent might be another control which is not a naming container.