定義
元資料最本質、最抽象的定義為：data about data (關於資料的資料)。它是一種廣泛存在的現象，在許多領域有其具體的定義和應用。
我的理解就是對資料進行說明、描述。不知道我的這個理解對不對？呵呵。
sql server 裡面有兩個表，我們可以用這個sql語句來檢視一下，我們可以看到資料庫裡面的表和字段的資訊。那麼這些資料是不是可以看做是一種「元資料」呢？
select
top100
percent
tbl.name
as表名, col.name
as欄位名, tt.name
as欄位型別,
有一些**生成器，會根據這個資訊來生成**，但是我覺得這些資訊還遠遠不夠，就是說描述的還不夠準確。當然了，如果只是生成實體類的定義，那還是夠用的，但是如果還想要生成ui裡面的**，那就不夠用了。因為我不知道乙個欄位在ui（具體一點，比如表單）裡面會以什麼控制項出現？是文字框還是下拉列表框？不能準確說明，那就是資訊不夠詳細，也就意味著生成出來的**還需要手動的修改。一修改就帶來了很多的問題，在這我就不想多說了，呵呵。
自然框架裡面的「元資料」指的是什麼呢？簡單的說就是表的說明、欄位的說明。當然還有元資料的組合方式，比如乙個表單裡面需要哪些字段，而這些欄位是可以從多個表裡面獲取。那麼這個表、欄位的說明和資料庫裡的那些有什麼不同呢？描述更加詳細。比如他描述了在表單裡面是什麼控制項、資料的驗證方式等等，而且還可以根據您的需要而酌情增加。
【表和字段的擴充套件資訊】
【乙個功能節點（表單）裡面需要的字段，可以是多個表裡的字段】
【又補充了乙個圖】
上面的圖好像有點亂，能做的事情實在是太多了。當然您可能覺得維護些麼多的元資料，成本太高了不划算，還不如直接寫**。還是寫出來的**用著放心，而且可以隨心所欲的去調整。這個就是仁者見仁智者見智的事情了吧，不同的人會有不同的結論。我只能說我習慣於依賴元資料。當然您也可以反對，也歡迎您說出您的理由。
這裡有乙個缺點，但是同時也是優點 —— 那就是太依賴元資料了。有了元資料，那麼什麼都好實現；沒有了元資料，那就什麼都做不了了。所以維護好元資料就成了重中之重！
除了這些還可以做其他的事情，因為這個元資料是比較基礎的，相信依據他，可以做出更多的事情。因為「只有想不到，沒有做不到！」
ps：關於業務邏輯層，我覺得這一層的**，**生成器是不應該可以生成出來的，如果真的生成出來了，那是不是應該懷疑一下設計是不是有點問題呢？呵呵。邏輯呀，是要根據具體的情況，通過大腦的思考、判斷，才能做出來的，對吧。**生成器，有那麼智慧型嗎？至少現在還不行吧。所以我覺得業務邏輯就要自己親自去寫**，呵呵。自然框架裡面的業務邏輯也不是靠滑鼠點出來的，也是需要手動編寫的。
關於**生成器，我還是建議盡量不要用，能不用就不用，是在不行了再用，呵呵。只不過我以前確實寫了幾個「**生成器」，當然只能算作半成品了。第乙個是利用excel，就是裡面的公式。我的資料庫文件就是用excel來做的，裡面有字段的說明，那麼我就可以利用公式，來生成一些我需要的**。這個是很簡陋的，但是在當初還是比較好用的。
後來用拼接字串的方式寫了乙個，那可是真的折磨呀，不改上幾個小時是弄不好的，現在看看那時候也是在是太笨了，呵呵。
再後來才寫出來了表單控制項，有了表單控制項，**生成器也就沒什麼用處了，通通交給表單控制項全權負責了。
不過現在又要寫**生成器了，因為我想要生成定義實體類用的**，呵呵。
自然框架 之「元資料」的威力
定義 元資料最本質 最抽象的定義為 data about data 關於資料的資料 它是一種廣泛存在的現象，在許多領域有其具體的定義和應用。我的理解就是對資料進行說明 描述。不知道我的這個理解對不對？呵呵。sql server 裡面有兩個表，我們可以用這個sql語句來檢視一下，我們可以看到資料庫裡面...
自然框架 自然框架的命名空間
為什麼要有命名空間？類多了不便於管理，把他們給他分個類整理一下，便於管理。那麼命名空間就有了兩個使命，分類和標識。其實標識也是一種分類。我們開啟reflector.exe看看.net框架裡的命名空間。system開頭，這個就是一種標識吧，表示這是.net框架提供的類，和第三方提供的類可以有乙個明確的...
自然框架 之「解耦」初探
解耦，在以前確實做不到，但是周四和 橫刀天笑 聊了之後，發現解耦是可以實現的。其實很簡單，只要弄出來乙個 實體類 就可以搞定了。如果是簡單的情況，那麼就讓表單控制項 全權負責 了，這時候是不需要些什麼 的，點點滑鼠，打幾個字就可以了。如果是有複雜的業務邏輯，那麼就可以定義乙個實體類，然後讓表單控制項...