上次说了一下在网页里面显示列表数据的情况，这个应用范围太小了，添加、修改怎么办呢？网站的后台管理、OA、CRM等怎么办？还是这样处理显然是不行的。
我们还是看一个小例子，这回是数据库设计的。
假设我们要做一个小学的成绩单，设计一个成绩表
小学生成绩表
字段：学生名称、语文成绩、数学成绩、美术成绩等。
小学里的课程是有限的，就那么几个，都作为字段放在表里面就ok了。
如果我们现在要做一个中学的成绩单呢？物理、化学、生物、地理、历史课程增加了不少，还是往用往表里面增加字段的方式吗？好像也勉强可以。
如果我们现在要做一个大学的成绩单呢？还用这种方法就绝对不行了。换一个方法吧，行列转换一下。
大学成绩单
字段：学生ID、课程ID、成绩
这样三个字段搞定，当然还可以再根据情况增加一个字段，比如系ID、专业ID等，没有真正做过，只是猜想。这样学生和课程就可以随意组合了。当然他有一个很大的缺点，就是显示成绩单的时候有点麻烦，但是这个不在本次讨论的范围内。
好了，回到程序的世界里面。上次我们定义了一个类用来显示列表数据，
public class Group_topic_Show
{
public string Topic; //话题名称
public string TopicURL; //话题的连接地址
public string Group; //话题所属小组的名称，来自“小组”表
public string GroupURL; //小组的连接地址
public string View; //回应/浏览
public string SendDate; //话题发表日期
public string Author; //作者姓名，也是来自另一个表
public string AuthorURL; //作者的连接地址
}
假设我们要往这个表里面添加数据怎么办呢？
等等这个类是用于显示数据的，添加的时候还可以使用这个类吗？好像不行了吧，要换成下面的形式
public class Group_topic
{
public string Topic; //话题名称
public string TopicURL; //话题的连接地址
public string GroupID; //话题所属小组的ID
public string View; //回应/浏览，这个可以不填（利用数据库的默认值），或者在程序里填0。
public string SendDate; //话题发表日期，这个一般也是取默认值
public string AuthorID; //作者姓名ID
public string Content; //主题内容
//其他字段
}
这就是第一个问题：数据库里有三个表（主题、分组、会员），发表主题的时候往一个表里面写数据就可以了，但是显示主题的时候还需要两外两个表里面的数据，那么这时候实体类如何定义呢？我这里想到了两种方案：
第一种方案：一个表只对应一个实体类，三个表就会有三个实体类，这样添加的时候没有什么问题，显示的时候就要用类的关系的方式联系到一起，具体怎么做我还不知道呢。
这样做有一个明显的缺点，就是在显示列表的时候，主题的内容也会被加载进来，但是在列表的时候根本就不需要，由于这个字段里面的数据量比较大，所以就显得很浪费资源！
第二种方案：添加的时候用一个实体类 Group_topic，显示的时候用另一个实体类 Group_topic_Show，就像上面定义的两个实体类。但是这个也有很明显的缺点，好多的字段名重复出现！如果这时候修改了字段名的话，修改量就会增倍！
这个就是我不想用三层的一个原因，总是要想实体类和数据表如何对应，很烦，左也不是，右也不是，不知道如何来做，那就干脆不用三层的这种形式吧。看了亚同学的帖子，好像他也有这样的问题？！我还以为只有我一个人有呢。
好了先不说这个问题了，我们继续。假设我们定义了一个 Group_topic类，要用这个类来实现添加、修改数据库。显示的问题先不考虑。
一般的步骤：
1、UI里面放置控件
2、取值，给实体类赋值
3、验证，逻辑处理
4、拼接SQL语句，或者设置存储过程的参数
5、提交给数据库
我见过的一种方式是这样的，数据层里写这样的代码
sql = "insert into Group_topic (Topic,GroupID,Author) values (@Topic,@GroupID,@Author)";
//添加存储过程的参数。
cmd.Parameters.Add("@GroupID", SqlDbType.Int).Value = fam.GroupID; //自动ID 1:为系统管理应用
这样写，我觉得挺繁琐的，为什么说繁琐呢？我们看看字段名出现了几次？(Topic,GroupID,Author)这里出现了一次，(@Topic,@GroupID,@Author)" 这里是第二次，("@GroupID", 又是一次，fam.GroupID 这是第四次了！
就是一个字段名呀，出现了四次，烦不烦呀，修改的时候，只是数据层就有四个地方，恐怖！虽然你可以使用代码生成器搞定，但是当需求有变化的时候呢，代码生成器可以很好的解决吗？
“嘻嘻哈哈”极力推荐我看一个ASP.NET权限管理系统的源代码，三层写的，上面的给参数赋值的语句就是从“权限管理系统”copy出来的。看了之后有几点心得：
1、他的代码真的像我上面写的过程，基本差不多。
2、我才知道为什么代码生成器会这么火，因为没有代码生成器的帮助，根本就没有办法写三层的代码。
3、抽象在哪里？相似的函数太多了。
Code
public override int sys_ApplicationsInsertUpdate(sys_ApplicationsTable fam)
{
int rInt = 0;
using (SqlConnection Conn = GetSqlConnection())
{
SqlCommand cmd = new SqlCommand("sys_ApplicationsInsertUpdateDelete", Conn);
cmd.CommandType = CommandType.StoredProcedure;
//设置参数
cmd.Parameters.Add("@DB_Option_Action_", SqlDbType.NVarChar).Value = fam.DB_Option_Action_; //操作方法 Insert:增加 Update:修改 Delete:删除 Disp:显示单笔记录
cmd.Parameters.Add("@ApplicationID", SqlDbType.Int).Value = fam.ApplicationID; //自动ID 1:为系统管理应用
cmd.Parameters.Add("@A_AppName", SqlDbType.NVarChar).Value = fam.A_AppName; //应用名称
cmd.Parameters.Add("@A_AppDescription", SqlDbType.NVarChar).Value = fam.A_AppDescription; //应用介绍
cmd.Parameters.Add("@A_AppUrl", SqlDbType.VarChar).Value = fam.A_AppUrl; //应用Url地址
Conn.Open();
rInt = Convert.ToInt32(cmd.ExecuteScalar());
cmd.Dispose();
Conn.Dispose();
Conn.Close();
}
return rInt;
}
/// <summary>
/// 返回sys_ApplicationsTable实体类的ArrayList对象
/// </summary>
/// <param name="qp">查询类</param>
/// <param name="RecordCount">返回记录总数</param>
/// <returns>sys_ApplicationsTable实体类的ArrayList对象</returns>
public override ArrayList sys_ApplicationsList(QueryParam qp, out int RecordCount)
{
PopulateDelegate mypd = new PopulateDelegate(base.Populatesys_Applications);
return this.GetObjectList(mypd, qp, out RecordCount);
}
像这样形式的函数出现了好多好多，估计项目越大，这样的函数就会越多！而且为了支持多种数据库，他写了三个文件SqlDataProvider.cs、OracleDataProvider.cs、AccessDataProvider.cs，这三个文件里的代码也都差不多。为什么要一边一边的写类似的函数呢？就是因为实体类的属性是不一样的！
有一点很奇怪，SQL SERVER使用存储过程，而ACCESS确实用参数化的SQL语句，为什么不都是用参数化的SQL语句呢？难道在SQL SERVER的存储过程里面还要做一些判断吗？
相似的代码重复出现，“重用”在哪里呢？！
为了解决这样的问题，有些同学提出来了使用反射，估计是使用反射地方法把属性名称反射成字段名称，再拼接参数化的SQL语句，然后再添加存储过程的参数。（不知道参数类型是如何得到的？）
这样倒是可行，但是效率上有一点点损耗，从原理上来说也是挺“郁闷”的，我们在编码的时候用字符换的形式定义了实体类的属性，然后编译，变成了一种形式，然后用的时候在通过反射，再把这种形式变回字符串的形式，绕了一圈，为什么绕圈圈呢？
所以我给实体类变一下形式，“行列转换”了一下。
class ColInfo()
{
public string ColName;
public string ColValue;
}
上面的属性就变成了这样
ColInfo tmpColInfo = new ColInfo();
tmpColInfo.ColName = "Topic";
tmpColInfo.ColValue ; //这个在定义的时候是没法赋值的，需要在UI里面赋值。
然后再放在一个集合里面，一个有属性（字段）组合而成的“类”（集合）就诞生了。这样我们就做到了以属性（字段）为最小单位进行随意组合，也可保证字段名在程序里面只出现一次，这样就大大减少了修改的机会。
保存数据的时候，代码也可以进一步的抽象，抽象成一个函数来处理。不用一个类写一套函数了，
只有两个属性还不够，字段类型怎么办呢？我们在扩充一下吧，加几个属性，
/// <summary>
/// 字段的基本信息的描述
/// </summary>
public class ColumnsInfoBase
{
#region 字段的基本信息的描述
/// <summary>
/// 配置信息里面的字段的标识
/// </summary>
public int ColumnID = 0;
/// <summary>
/// 数据库里的字段名称
/// </summary>
public string ColSysName = "";
/// <summary>
/// 显示给客户看的名称
/// </summary>
public string ColName = "";
/// <summary>
/// 字段类型，int nvarchar 等
/// </summary>
public string ColType = "";
/// <summary>
/// 字段大小
/// </summary>
public Int32 ColSize = 0;
/// <summary>
/// 字段值
/// </summary>
public string ColValue;
/// <summary>
/// 查询方式
/// </summary>
public Int32 FindKind = 0;
#endregion
}
这样呢，我们就可以根据这些信息来拼接参数化的SQL语句和存储过程的参数了。
对了，集合的方式还没有写呢，
Code
Dictionary<int, ColumnsInfoForm> dic_BaseCols = new Dictionary<int, ColumnsInfoForm>();
ColumnsInfoForm info;
foreach (DataRow dr in dt.Rows)
{
info = new ColumnsInfoForm();
info.ColumnID = Int32.Parse(dr["ColumnID"].ToString());
info.ColSysName = dr["ColSysName"].ToString();
info.ColName = dr["ColName"].ToString();
info.ColType = dr["ColType"].ToString();
info.ColSize = (Int32)dr["ColSize"];
info.FindKind = (Int32)dr["FindKind"];
dic_BaseCols.Add(info.ColumnID, info);
}
为什么 key 不用字段名而用字段ID呢？因为字段名是“不可靠”的，字段名是会变的呀，变了怎么办呀？就会有修改代码的可能。当然也不是说字段ID是绝对不会变化的，字段ID只会被“删除”，而不会被修改，字段ID要比字段名稳定很多，因为字段ID是与业务逻辑一点关系都没有的，而字段名多少和业务逻辑是有关联的。
不过这样“实体类”就由装载数据变成了对字段的描述，有了这些信息，我们就可以用作拼接SQL语句（参数化的或者非参数化的），设置存储过程的参数，加上查询方式，就可以拼接“查询条件”，就是SQL语句的Where后面的部分。
一个函数就可以搞定了，不用写这么多的类似的函数了！我们可以继续进行扩展，可以描述字段在UI里的表现形式，比如用什么控件（文本框、下拉列表框还是复选框等），验证方式等。还有就是表单的布局。可以描述列表的表现形式，那个字段在前面，那个在后面，是否需要格式化（Format）等。
其实这个就是我的表单控件、查询控件、显示数据的控件里面使用的一种载体。一开始写的时候还没有意识到，写完了之后才发现，自己居然写成了这种形式。当然在我的控件里面，类的加载（实例化）都是依据配置信息来做的。
优点：
1、以字段为最小单位。这样数据表里面的字段，在“代码”里面只会出现一次，然后可以让他们灵活的组合，不管是那个表里的字段都可以组合在一起，放在一个集合里面。
2、需要字段名的时候，使用 属性就可以了，不用反射了。
第一个优点是相对于现在三层里面的实体类来说的，三层里的实体类都是以表为最小单位的，属性只能是类里面的一部分，不能独立存在，这样就很不灵活，这就是第一个问题的由来。