为了保持整个系统有足够的扩展和足够的弹性（能够满足灾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就支持了新的控