自然框架里面采用了两种映射关系，一个是流行的ORM，另一是非主流的“CCM ” （我自己想的，呵呵）。
先说一下ORM。ORM是O和R的映射关系。也看到很多人写关于ORM的文章，发现好像有个误区。这个误区就是，要么根据数据库来生成实体类，要么根据实体类（UML）来生成数据库。ORM有这么简单吗？这个误区导致了一个很严重的问题——滥用！！
用好ORM的关键，我举的在于：设计O的时候是否会受到R的影响；同理，设计R的时候，是否受到了O的影响？也就是说设计实体类的时候，完全不去考虑数据库，设计数据库的时候也完全不考虑实体类！
用实际的工作经历来说明一下。我在做设计的时候，先根据需求设计数据库，这时候完全没有考虑类要如何设计（其实一开始根本就没有用实体类，呵呵）。
后来框架不断扩展，发现个问题：不弄个实体类来管理一下，确实挺麻烦的。那么如何来设计需要的类呢？
有一个表就建立一个类，表里的字段都是类的属性吗？真的是真么简单吗？
既然要设计类，那么就要把表结构忘掉，完全按照实际需求和面向对象的要求来设计。然后类和数据库都设计好了之后，再去考虑如何映射。我觉得只有这样做的才是真正的ORM。
比如：自然框架元数据的数据库里有一个表“Manage_Columns”，他是记录字段的基本信息（字段名、字段类型、字段大小等）和验证信息、控件描述等。因为这些信息都是跟随字段的，所以就都放在了一个表里面。
实体类里有一个类“ColumnMeta”，他的属性只有字段的基本信息，没有验证信息等。这是因为这个信息是很多地方都需要用到，而验证信息并不是必须的。只有页面表单里面才需要，“数据列表”和“数据查询”都不需要。
这样一来，表和类就不是完全对应，而是把一个表“拆开”了，对应多个类。
在比如：表单里的控件有很多种类，文本框、下拉列表框、多选等，而文本框有分为单行、多行、密码等，还有日期选择等等情况。那么如何来描述这些不同类型的控件呢？把属性都拿出来做成字段？还是把不同的控件都拿出来做成表？
这两种方法都有很明显的缺点——不便于维护！多一种控件，就要多一些字段，或者多一个表。这样就给扩展带来了麻烦，修改的时候也很麻烦！想一想，自然框架推广了（假设一下，呵呵）。好多人都在用，突然告诉大家，数据库里要多两个字段。不把这两个字段加上，就不能用新版本。这是一件多么麻烦的事情呀。
要尽量避免这种事情，那么要怎么处理呢？我的解决方法就是——在数据库里就设置一个字段，然后把描述信息都放进去。一开始采用~来分隔，后来发现不太便于查看。于是现在新版本采用json的格式来做控件信息的描述。然后把整个描述信息放在一个字段里。这样怎么扩展，数据库都不需要有变化了。
再来看看实体类的设计。数据库里用一个字段，那么实体类不能只有一个属性来表示，这样就太不方便了。于是设计了一套类。如下图。采用基类的方式。这样，数据库里的一个字段，就对应了一套类。
=====================================================
另外ORM还有一个小问题，就是ORM的粒度只是做到实体类和表。并没有做字段。在ORM里字段是不能独立存在的，这样就造成了一个麻烦——多表关联的怎么办？
所以就想出来了——CCM。
CCM是啥呢？就是 control 、column的映射。页面里的控件和数据库里的字段，直接对应起来。
Control指的是文本框、下拉列表框这一类的控件，不包括GridView这一类的控件。
我是用一种“映射”，把字段和控件关联起来，实现快速开发。他的粒度更细了一层，字段是可以独立出来的，并不限于一个表内。于是字段就可以“复用”。一个字段（的描述信息）就是一条记录，表单里需要的字段就是一个集合，数据列表里需要的字段是另一个集合……这样就非常方便。这样处理带来了很多好处，最明显的就是——权限到字段！
