实体类的变形【2】—— 行列转换

     上次说了一下在网页里面显示列表数据的情况，这个应用范围太小了，添加、修改怎么办呢？网站的后台管理、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、抽象在哪里？相似的函数太多了。

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语句和存储过程的参数了。

对了，集合的方式还没有写呢，

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、需要字段名的时候，使用 属性就可以了，不用反射了。

     第一个优点是相对于现在三层里面的实体类来说的，三层里的实体类都是以表为最小单位的，属性只能是类里面的一部分，不能独立存在，这样就很不灵活，这就是第一个问题的由来。