为了保持整个系统有足够的扩展和足够的弹性（能够满足灾WebForm和WinForm中的使用，以及其他数据库更新的来源，比如说Office 2003中InfoPath，以及WebService等等），我将整个DBForm的构架拆分为FormInfo类和SqlBuilder两个基类，下面分别描述FormInfo类和SqlBuilder类的作用以及申明
FormInfo主要负责整个数据库Field信息的抓取，主要包括了以下两个方法：
/// 添加将要进行遍历的容器、
public virtual void AppendContainer(object AContainer)
/// 添加单个控件
public virtual void AppendControl(object AControl)
/// 清除先前已经配置好的Form信息
public void ClearFormInfo()
主要提供了两个虚方法，一个公开的ClearFormInfo方法，从方法名称上面的含义大家看得很清楚了，整个FormInfo可以根据容器和单独的控件进行添加，在这里，我有必要说明一下我的DBForm架构中针对Winform和WebForm的扩展，因为下面的WinFormInfo类和WebFormInfo类分别继承自FormInfo,实现WinForm和WebForm的信息提取
再WinFormInfo和WebFormInfo中，主要是一个针对Container的循环，以及通过重写AppendContainer实现
/// 添加将要进行遍历的容器
public override void AppendContainer(object AContainer)
{
System.Web.UI.Control Container = (System.Web.UI.Control)AContainer;
foreach(Control AControl in Container.Controls)
{
this.DoAppendControl(AControl);
}
}
在下面的WebQueryForm和WebModifyForm中，就是实现具体的Form信息提取了。为什么要用这么多类的继承呢？我觉得这样的视线，主要有以下几点好处
1． FormInfo类主要提供最公开的接口，以及一些基础的方法（提供了一个protected的方法，用于将分析出的Form信息填充入FormInfoEntity中（窗体信息的描述类）
2． WinFormInfo和WebFormInfo类主要是把容器Object转换成为具体的WinContrl和WebControl，并且调用相应的控件信息解析器，实现数据的提取。
3． 接下来的ModifyFormInfo和QueryFormInfo主要就提供了控件的信息解析器具体实现，根据具体的控件和具体的任务（Modify呢还是Query）分别解析出控件的信息，比如说QueryFormInfo中需要加入相关操作符号的信息（LIKE，=等等）
下面是具体控件的添加操作
private void DoAppendControl(System.Web.UI.Control AControl)
{
if (AControl is SmisNet.WebControl.SmisDropDown)
{
this.DoAppendDropDownList(AControl as SmisNet.WebControl.SmisDropDown);
}
else if (AControl is System.Web.UI.WebControls.TextBox)
{
this.DoAppendTextBox(AControl as SmisNet.WebControl.SmisTextBox);
}
else if (AControl is System.Web.UI.WebControls.ListBox)
{
this.DoAppendListBox((System.Web.UI.WebControls.ListBox)AControl);
}
}
其实这部分代码写得并不算优美，包括DoAppendDropDownList等方法都写成了虚方法，有不少代码的臭味到。其实不应该这样的，只是因为我们现在的工作比较简单（只有这三种窗体，不过我想包括了大多数信息系统开发的情况）如果您使用了其他的控件，可以考虑修改AControl is xxx，然后天加上自己的控件的处理方法，FormInfo就支持了新的控
……