定義
中繼資料最本質、最抽象的定義為：data about data (關于資料的資料)。它是一種廣泛存在的現象，在許多領域有其具體的定義和應用。
我的了解就是對資料進行說明、描述。不知道我的這個了解對不對？呵呵。
SQL Server 裡面有兩個表，我們可以用這個SQL語句來檢視一下，我們可以看到資料庫裡面的表和字段的資訊。那麼這些資料是不是可以看做是一種“中繼資料”呢？
SELECT TOP 100 PERCENT tbl.name AS 表名, col.name AS 字段名, tt.name AS 字段類型,
col.length
FROM dbo.syscolumns col INNER JOIN
dbo.sysobjects tbl ON col.id = tbl.id INNER JOIN
dbo.systypes tt ON col.xtype = tt.xtype
WHERE (tbl.xtype = 'u') AND (tt.name <> N'sysname')
ORDER BY tbl.name, col.colid
有一些代碼生成器，會根據這個資訊來生成代碼，但是我覺得這些資訊還遠遠不夠，就是說描述的還不夠準确。當然了，如果隻是生成實體類的定義，那還是夠用的，但是如果還想要生成UI裡面的代碼，那就不夠用了。因為我不知道一個字段在UI（具體一點，比如表單）裡面會以什麼控件出現？是文本框還是下拉清單框？不能準确說明，那就是資訊不夠詳細，也就意味着生成出來的代碼還需要手動的修改。一修改就帶來了很多的問題，在這我就不想多說了，呵呵。
自然架構裡面的“中繼資料”指的是什麼呢？簡單的說就是表的說明、字段的說明。當然還有中繼資料的組合方式，比如一個表單裡面需要哪些字段，而這些字段是可以從多個表裡面擷取。那麼這個表、字段的說明和資料庫裡的那些有什麼不同呢？描述更加詳細。比如他描述了在表單裡面是什麼控件、資料的驗證方式等等，而且還可以根據您的需要而酌情增加。
【表和字段的擴充資訊】
【一個功能節點（表單）裡面需要的字段，可以是多個表裡的字段】
有了更加準确的描述，那麼我們就可以做更多的事情，同時也可以做的更好，更準确。那麼到底能做什麼呢？請看下圖：
【又補充了一個圖】
上面的圖好像有點亂，能做的事情實在是太多了。當然您可能覺得維護些麼多的中繼資料，成本太高了不劃算，還不如直接寫代碼。還是寫出來的代碼用着放心，而且可以随心所欲的去調整。這個就是仁者見仁智者見智的事情了吧，不同的人會有不同的結論。我隻能說我習慣于依賴中繼資料。當然您也可以反對，也歡迎您說出您的理由。
這裡有一個缺點，但是同時也是優點 —— 那就是太依賴中繼資料了。有了中繼資料，那麼什麼都好實作；沒有了中繼資料，那就什麼都做不了了。是以維護好中繼資料就成了重中之重！
除了這些還可以做其他的事情，因為這個中繼資料是比較基礎的，相信依據他，可以做出更多的事情。因為“隻有想不到，沒有做不到！”
ps：
關于業務邏輯層，我覺得這一層的代碼，代碼生成器是不應該可以生成出來的，如果真的生成出來了，那是不是應該懷疑一下設計是不是有點問題呢？呵呵。邏輯呀，是要根據具體的情況，通過大腦的思考、判斷，才能做出來的，對吧。代碼生成器，有那麼智能嗎？至少現在還不行吧。是以我覺得業務邏輯就要自己親自去寫代碼，呵呵。自然架構裡面的業務邏輯也不是靠滑鼠點出來的，也是需要手動編寫的。
關于代碼生成器，我還是建議盡量不要用，能不用就不用，是在不行了再用，呵呵。隻不過我以前确實寫了幾個“代碼生成器”，當然隻能算作半成品了。第一個是利用Excel，就是裡面的公式。我的資料庫文檔就是用Excel來做的，裡面有字段的說明，那麼我就可以利用公式，來生成一些我需要的代碼。這個是很簡陋的，但是在當初還是比較好用的。
後來用拼接字元串的方式寫了一個，那可是真的折磨呀，不改上幾個小時是弄不好的，現在看看那時候也是在是太笨了，呵呵。
再後來才寫出來了表單控件，有了表單控件，代碼生成器也就沒什麼用處了，通通交給表單控件全權負責了。
不過現在又要寫代碼生成器了，因為我想要生成定義實體類用的代碼，呵呵。