自然架構裡面采用了兩種映射關系，一個是流行的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這一類的控件。
我是用一種“映射”，把字段和控件關聯起來，實作快速開發。他的粒度更細了一層，字段是可以獨立出來的，并不限于一個表内。于是字段就可以“複用”。一個字段（的描述資訊）就是一條記錄，表單裡需要的字段就是一個集合，資料清單裡需要的字段是另一個集合……這樣就非常友善。這樣處理帶來了很多好處，最明顯的就是——權限到字段！
