閱讀目錄：

• 1.開篇介紹
• 2.Model與View的使用關係（資料上下文DataContext與View呈現）
• 3.Metadata元資料驅動設計（如何使用中間層元資料來驅動最終的行為）
• 4.ASP.NETMVC ModelMetadata（ModelMetadata元資料如何支撐Model與View之間的組合關係）

1】開篇介紹

這篇文章讓我們一起來學習一下有關Asp.netMvc中的Mode元資料的相關設計和圍繞元資料的一些其他物件模型，他們是如何通過彼此協調來支撐起一個靈活的介面程式設計介面；

其實提到元資料（Metadata）大家在研究某個應用框架的時候都曾經或多或少的見到過，可能並沒有引起你的注意；其實在很多應用框架中我們都能看見Matedata的影子，它是一個很不錯的框架設計模式，俗稱：“元資料驅動設計”

，它跟目前很多設計思想很接近，如：超程式設計、契約式設計，這些模式目的都是為了能很好的控制耦合，產生極大的擴充套件靈活性；超程式設計讓我們能基於最終的使用者選擇動態的產生執行軟體的程式碼，而契約式設計能讓我們將控制權設立在很遠的地方，從而很大粒度的控制擴充套件性，根據契約設立規則，控制端再在執行時動態的生成出最終需要的規則；

通過對這些模式深入理解，基本上可以提煉出兩條設計上的黃金規則：1.將變化點從編譯時遷移到執行時；2.將變化點從硬編碼遷移到配置化；

這裡只是一個簡單的介紹，由於每一個主題細化下來都會很大，都會包含該方向中的很多領域概念、術語和重要的設計思想，所以這裡只是一個簡單的介紹，本篇文章會重點介紹一下“元資料驅動設計

”程式設計思想和它到底好在哪裡，然後在ASP.NETMVC中它起到怎樣的作用，它又是如何架起通往Model與View的高速橋樑的，讓Model與View可以到做1對N的搭配關係，在大型站點中ViewModel一般只有固定的幾種，但是View可能會有成千種，如何做到這種高度適配，這就是自定義模板的功能，當然一切都建立在ModelMetadata基礎上；

2】Model與View的使用關係（資料上下文DataContext與View呈現）

在MVC的定義中，Model準確點講是ViewModel而非DomainModel，ViewModel簡稱顯示Model，主要是將要顯示的資料融合在一個DataContext中，它來源於企業應用架構中的Query端的資料來源；一般情況下這樣的一個ViewModel不會經常變化，都是根據眾多的業務場景抽象出來的一個比較Common的資料上下文；

在網站型的系統中，尤其電子商務平臺，介面的變化很常見，幾乎每天都有可能改變介面上的某個顯示方式，同樣一組資料可能在UI上的展現方式各不相同；這裡就會形成一個Model與多個View的組合關係，同樣一個Promotion（促銷）資料上下文，需要在很多登出類別不同的UI上展現，而不同的UI組成都是由不同的View的負責生成；

圖1：

可以總結出一個數據上下文實體在大部分的情況下都可能會被很多View使用，所以ASP.NETMVC 需要具備很強的自定義性，一個Model可以隨意呈現出多中Ui而不會因此將ViewModel搞的一團亂；

注意：一個ViewModel資料實體可能很大，如果為了應付不同的顯示場景最好將ViewModel進行切割，拉出繼承體系，而不是將所有的ViewModel耦合在一個超大的ViewModel中，這樣會讓每一次的查詢都會涉及到一些你本次不相關的屬性；

3.Metadata元資料驅動設計（如何使用中間層元資料來驅動最終的行為）

元資料驅動設計模式是眾多經典框架設計模式之一，它與契約式設計有點一脈相承的感覺；其實框架設計的本質是如何靈活的運用一些框架設計模式，不同的語言、平臺對模式的運用各不相同，但是模式的中心思想一直不會變，不管你如何設計都必須呈現出框架模式的本質才行；

在眾多的框架設計模式中 如：契約式設計、超程式設計、元資料驅動設計、管道模型、遠端代理模式、提供程式模型；元資料驅動設計模式是使用頻率比較高的，因為其複雜度也相對較低所以比較容易上手；其實在很多現有的.NET框架中，如：WCF、ASP.NET、Remoting、Winform中都會看見Metadata的影子，但是不一定非得要在命名的時候加上Metadata，有很多的時候也會使用Description來代替；

元資料通常作為支援資料，它是描述資料的資料，是真正被解析處理的資料；既然是描述資料的資料，那麼就存在它在那個方向上的描述，描述的角度是什麼，描述的層面又是是什麼；

我們就拿ModelMetadata來講，在ASP.NETMVC中，Model的使用方向基本上被限定在三個操作集合中，第一：請求的資料繫結，第二：資料繫結時的驗證，第三：Model的最終呈現；那麼ModelMetadata要包含這三個操作集合所需要的全部資料，當然也可以通過切割成三組元資料物件模型，通過繼承體系包含起來；那麼ModelMetadata需要描述三個方向上的所需要的資料集合，Model本身就是一中資料，而通過使用ModelMetadata來抽象的描述第二個層面上的資料，從三個操作集合角度中包含使用的資料，也就是說三個角度，兩個層面；如果你的框架需要具備多個層面，那就需要進一步細化抽象；

圖2：

標準資料經過一箇中間的環節轉換成元資料，然後交給最終的處理程式去使用；可以很清晰的瞭解到元資料起到的一個核心作用，它可以很好的將處理程式與標準資料之間解耦，讓中間的元資料提供更大的靈活性，通過這個中間層元資料，我們可以很輕鬆的做到對元資料進行配置；

我們假設沒有中間層元資料，操作程式不管如何設計都會和標準資料實體有耦合，而且要保證標準資料的純潔度，不可能總是對它使用繼承、特性等重度汙染性的侵入，保證完全的POCO（Plain Old Csharp Objects）物件很難，如果沒有IDE的編譯時支援，很難提取出可以在執行時使用的資料；這個時候我們如果需要修改標準元資料的型別或者修改操作程式的邏輯都會或多或少的對兩者有影響；

如果使用元資料我們完全可以將表資料對元資料的定義部分遷移到配置檔案中去，然後再在元資料提供程式中擴充套件讀取元資料的源頭，可以做到將標準資料放在任何地方甚至遙遠的雲平臺上，對於操作程式來說，我們可以將獲取元資料的介面提取成Service方式，從任何一個地方讀取元資料；

這些種種方案你可能決定永遠都不會用到，但是誰又能把某個框架的所有功能都用一邊呢，系統需求各異，都有可能需要這些擴充套件點；

4.ASP.NETMVC ModelMetadata（ModelMetadata元資料如何支撐Model與View之間的組合關係）

未完待續，敬請關注......