.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://wangqingpei557.blog.51cto.com/

本文版權歸作者和51CTO共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利。