既然见到了公司，我们可以定义一个Class Company ，那么我们见到了字段，是不是也可以定义一个Class ColumnInfo呢？

 

公司的描述信息类：

 

 

字段的描述信息类

 

 

　　定义Company是为了保存公司相关的一些信息，那么定义ColumnInfo是为了什么呢？自然是要记录字段的相关信息了，比如字段名、字段大小、字段类型等，然后等到用的时候就可以直接获取了。

　　我知道有的方法是采用XML来记录这些信息，然后和Company这样的类作对应，还有个方法是采用“特性”，把这些信息记录到特性里面。那么我为什么要定义一个ColumnInfo来记录这些信息呢？

　　前两种方法有两个特点：编译前确定、类爆炸。
　　

　　前两种方法都是以面向对象为主，先根据现实里的情况来定义实体类，然后在想办法把实体类和数据库对应上。在.net里面是在运行时类的结构就不能在变化了。如果要改变类的结构或者改个类名，都需要修改代码然后重新编译才行。

　　这样的话对于信息管理的项目就很麻烦了。比如公司信息，今天调研的时候客户说只需要六个属性就可以了，但是第二天可能就要提出来在加上一个公司地址。等到了上线运行的时候又提出来需要加上电子信箱。当然了这些都是小修小改，比这麻烦的改动大家也都见得多了吧。

　　应对这样的需求变化，就需要修改实体类。虽然有代码生成器，虽然有各种ORM，但是类的定义还是要改的吧。而且修改之后必须重新编译，更新文件才行。
我是比较烦修改代码的，改来改去就改乱了。

 

　　类爆炸，见到了员工定义一个Personal，见到了公司定义一个Company……这就是类爆炸。一个项目下来，几十个、上百个实体类，这些实体类都负责什么功能呢？有一大半都是只实现了增删改查，就完成任务了，说白了就是传递一下数据。如果只是为了传递数据而定义这么多的实体类，在我看来真的是很浪费的。很多不必要的修改量也是由此而产生的。

　　当然了如果您定义实体类是为了实现很复杂的业务逻辑的话，那就另当别论了。

如何解决呢？我们先看看我们想要达到什么目的？信息的增删改查。那么信息要放在哪里呢？关系型数据库（如果您的数据不是放在关系型数据库的话，那么不在本次讨论的范围内）。不管是员工信息、公司信息还是产品信息，都是数据库里的一条条数据。既然都是数据，那么就都要和字段打交道。那么我们是不是可以从这个角度来抽象一下呢？

 

　　ColumnInfo就是我的抽象的结果。每一个字段都是一个实例，比如Company的CompanyName是一个实例，City又是一个实例，这些实例放在一个集合（我采用了字典Dictionary）里面，就可以表达一个完整的含义。

 

　　这样不管信息如何变化，如何增加都不需要修改ColumnInfo的结构，这样就避免的类爆炸，当然换成了“实例爆炸”，不过实例可是要比类好管理多了。
ColumnInfo是通过属性值来区分的，那么就意味着我可以在运行时决定属性值。像字段名有变化这样的修改，就完全不用修改代码。

这还带来了另外一个优点。由于是以字段为最小单位，字段可以灵活的组合，同一个字段既可以放在集合A里面，又可以放在集合B里面。这样就解决了字段复用的问题。

 

延伸：
　　字段在添加、修改的时候需要对应一个控件，比如CompanyName要对应一个文本框，City要对应一个下拉列表框。那么我们是不是可以把控件也描述一下，并且把字段和控件对应起来。这样我们就可以在表单页面里根据这些信息来动态生成各种控件了。
【类图】

 

 

　　以字段信息为父类，生成（派生）了两个子类：列表，表单。表单又生成了两个子类：添加/修改，查询。为了准确描述各种控件各自特点的信息，又定义了一个ControlInfo，在这里定义控件的特殊属性。

 

　　根据“表单类”可以绘制表单，实现添加、修改数据的功能，或者是查询数据时候的查询条件的录入。
　　列表类可以绘制表格（<table>），还可以导出Excel。

　　FunctionInfo是功能节点的描述信息，里面包含三个类：分页信息（相当于显示数据和查询数据）；添加、修改、删除用信息；页面信息。

 

　　这就是自然框架的元数据，也就是描述信息，是自然框架的“灵魂”。

　　自然框架的元数据就相当于盖大楼用的图纸，乐队演奏音乐用的乐谱。

 

GridInfo类的代码：

 

 

 FormInfo类的代码

 

 ModInfo类的代码：