.NET/ASP.NETMVC 深刻剖析 Model元數據、HtmlHelper、自定義模板、模板的裝飾者模式（一）

閱讀目錄：

• 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之間的組合關係）

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

 

做者：王清培

出處：http://www.cnblogs.com/wangiqngpei557/

本文版權歸做者和博客園共有，歡迎轉載，但未經做者贊成必須保留此段聲明，且在文章頁面