?

?

Maverick.Net介紹

Maverick.Net是Java社區開源MVC Web框架Maverick的.Net版本，相關資料可以查看項目主頁。 不管Maverick.Net的是非好壞，了解一下它的思想還是不錯的。下面的內容是對Maverick.Net整體做一個簡單的介紹，以求能夠從全局的角度了解Maverick.Net一些相關概念，大致如何工作。 另外，本人沒有使用Maverick.Net開發過項目，只是看了它的架構、源碼之后有一些想法，跟大家分享一下，也希望能為想了解Maverick.Net的人提供些參考。 1. 主框架 Maverick.Net處理HttpRequest典型的流程如下圖： 圖一：處理請求 Reference:MaverickLite Specification Maverick.Net將每一個HttpRequest映射成Command。很容易看到，Command的提交者為用戶界面，也就是View；處理者應當是業務邏輯的控制器，也就是Controller。這樣，Maverick.Net Framework在處理每一個Command時，主要是解決下面的問題：如何從用戶界面（View）提交的參數生成Model？用哪個Controller處理特定的Command以及如何將Model傳遞給這個Controller？Controller處理結束之后如何將處理結果呈現給用戶（對Maverick.Net而言就是根據Controller處理結果，選擇返回哪個View給用戶界面）以及如何將Model傳遞給返回的結果View？ Maverick.Net通過一個配置文件進行配置，典型的Command配置節點如下： 這是Maverick.Net項目例子Friendbook中一個提交用戶注冊的Command配置節點。Dispatcher接收到提交注冊的HttpRequest之后，得到signupSubmit的Command Name，從而可以得到這個Command對象。Command將創建指定的Controller對象Friendbook.Ctl.SignupSubmit.Friendbook，并調用Controller進行處理。Controller處理結果應當是注冊成功，需要轉向注冊成功之后的View；或者是發生錯誤，需要轉向重新填寫注冊資料的View。Maverick.Net Framework規定Controller的返回結果必須是一個View的名字，這樣，Command調用Controller處理之后，就知道應該呈現哪個View對象。上圖中，如果注冊成功（success），將調用name="success"的View；如果注冊出錯，例如兩次輸入的密碼不一致等，將調用name="error"的View。name="success"的View類型為redirect，將使用當前的MaverickContext對象（聚合了HttpContext、Model等對象）重定向到另外一個名稱為edit.m的Command對象（View的類型等后面再介紹）；name="error"的View類型為document（默認類型，不需要寫type="document"），將直接使用Server.Execute()方法得到View的HTML輸出，并使用Transform對象，將用戶注冊結果View的HTML輸出轉換成整體頁面的HTML代碼，返回給客戶端（Transform的概念，后面再介紹）。 2. 主要的類、對象 Maverick.Net主要的類或對象如下：Dispatcher、Command、Controller、View、Transform、MaverickContext。 2.1 Dispatcher Dispatcher是一個HttpHandler類，用于攔截和處理HttpRequest，HttpRequest-Command的映射就是通過Dispatcher完成。 典型的情況下，Maverick.Net使用.m后綴作為ISAPI擴展，映射到Command。這種情況下，所有瀏覽器端提交的HttpRequest，請求的都是以.m結束的虛擬文件名，被提交給Dispatcher。這個文件在服務器上并不存在，Dispatcher接收到類似login.m的請求之后，將.m后綴去掉，取login作為Command Name，獲取Command對象，處理請求。 Maverick.Net老的版本基本上就是照搬Java版本的Maverick，在View的層面上只支持象JSP中Servlet的寫法，也就是純粹的ASP方式，或者是以ASP方式編寫的的aspx頁面。ASP.Net環境下ViewState、Postback事件機制、用戶控件等這些特性都不能使用，這對于ASP.Net環境是一種很大的損失。1.2版本開始，Maverick.Net的Controller比較完全的支持aspx的服務器端控件、用戶控件等，這樣就可以使用Maverick.Net框架，又基于ASP.Net進行設計和開發。 在使用aspx類型的Controller時，Dispatcher的攔截作用被去掉了，而是使用ASP.Net默認的HttpHandler，頁面類繼承Maverick.Ctl.Aspx.ControllablePage，ControllablePage在頁面的Render方法中切入Maverick.Net框架的控制。這種情況下，Command Name也不再是.m后綴方式，而直接變成對應的aspx頁面名稱，例如<command name="Default.aspx">。 另外，Dispatcher處理請求時，負責構造MaverickContext對象，使Command、Controller、View、Transform等在各自的處理期間，都能夠得到相應的上下文信息。 2.2 Command Command的作用類似一個指揮官，它根據Maverick.config文件的配置創建Controller對象，調用Controller進行處理；根據Controller的返回結果，選擇相應的View對象并執行。 Command可以沒有Controller，這種情況下，對Command的請求，實際上就是將特定的View呈現給客戶端。在Maverick.Net中，這是CommandSingleView。 另外，也可以繼承ICommand接口實現一些特殊功能或者說自定義的Command，例如Maverick.Net框架本身實現了兩個特殊的Command：ReloadCommand和CurrentConfigCommand。CurrentConfigCommand用于查看當前配置文件的內容，這個Command讀取Maverick.config配置文件的內容，直接輸出配置文件中的xml。另外，Maverick.Net在第一次處理請求的時候，會讀取Maverick.config中的內容，根據配置創建Command、View、Transform對象并緩存起來，后續的請求只是從緩存中取相應的對象。如果在第一次訪問之后這些配置有更新，這些更新不會立即反映到緩存的對象中。ReloadCommand的作用就是根據當前的Maverick.config配置文件內容，重新創建緩存的對象。 2.3 Controller Controller的職責是負責業務邏輯的處理。 在典型的應用中，Controller首先通過MaverickContext中的HttpContext對象，獲取從用戶界面也就是View提交過來的參數，創建Model對象，使用Model完成對請求的業務邏輯處理。Controller不同的處理結果，將用來確定選擇哪個View。在Controller的處理過程中可能會對Model進行更新，或者是有一些參數需要傳遞給View，這些將通過MaverickContext這個上下文信息對象完成。 在aspx類型的Controller中，因為Dispatcher的攔截作用被丟棄，因此MaverickContext對象的創建，也是在Controller中完成的。 2.4 View MVC的概念中，View負責將某個特定的Model，或者是整個Business Domain Model中某些角度的切片呈現給客戶端。Maverick.Net中，將View分成多種類型。 DocumentView：這是默認的View類型。這類型的View將配置一個文件，可能是asp或者aspx或者html等，調用Server.Execute()方法得到HTML的輸出，發送給客戶端。 ForwardView：這類型的View使用當前的MaverickContext重定向到另外一個Command去執行。如果基于structs的方式做系統分析設計，一個業務操作可能會被分解成很多個Command/Action，將這些Command/Action組合起來就形成一個新的Command/Action，或者就對應到某一個業務操作。forward類型的View是用于對這種形式的支持。 RedirectView：這類型的View，將直接使用Response.Redirect()方法重定向過去。因此也可以將forward類型的View看作是redirect類型的一個特例。實際上在Maverick.Net項目的示例中就有不少這樣的用法。這是因為Dispatcher攔截了HttpRequest，類似Response.Redirect("edit.m")的語句執行后，仍然會被Dispatcher攔截，開始一個新的Command的執行。 TrivialView：這類型的View，Maverick.Net將MaverickContext的Model對象直接進行輸出（取出內容，直接輸出）。這要求MaverickContext的Model對象是下面幾種類型：String、System.Text.StringBuilder、System.IO.TextReader、Sytem.Xml.XmlNode。 XmlSerializingView：這類型的View，將MaverickContext的Model序列化成xml格式后輸出。這種View主要用于基于xml的網站方案，或者是提供系統接口之用途。 2.5 Transform 在Maverick.Net看來，View執行的結果，還不是呈現給客戶端的最終輸出，之間必須經由Transform進行相應的轉換。 Maverick.Net實現的Transform有：DocumentTransform、XsltTransform。從XsltTransform類型更容易理解Maverick.Net的Transform概念。對應于XsltTransform，View是一個xml或者是XmlSerializing類型的View，為了將這個xml轉換成HTML輸出，需要使用xsl/xslt文件進行轉換，這就是XsltTransform的工作。 對于DocumentTransform的理解，Transform這個單詞意義上有點牽強。首先，DocumentTransform是針對于asp、aspx、html這種文檔類型的View。在我們的映象里，這種類型的View，Maverick.Net使用的是Server.Execute()方法，這樣已經直接得到HTML代碼，何必再經過一個DocumentTransform處理？ 實際上，對于一個系統，工作頁面會被分成不同的區域，例如頁面的Banner區、菜單/功能列表區、通用工具欄等等。這些不同的區域，在后面是由不同的Controller負責處理，對應的也是不同的Model。在Command的處理中，特定的Command只會使用自己的Controller對象，負責對相應的Model進行處理，因此也只應當對頁面中它所轄區域的顯示負責。這樣，View執行的結果就只是Command所轄區域的更新，而并不是整個頁面。至于如何將這個區域的更新顯示在整個頁面中，這就是DocumentTransform的工作。 目前Maverick.Net對于DocumentTransform用如下方式進行處理。假如是一個document類型的View，對應一個aspx文件。View在執行時使用Server.Execute()方法得到輸出的HTML代碼。但這個還不是最終發向客戶端的完整輸出，而只是其中的一部分，Maverick.Net將這個HTML片斷保存在HttpContext.Items[""]中。DocumentTransform對象對應的也是一個aspx的頁面，這個頁面應當完成系統頁面的整體布局，并從HttpContext.Items[""]中取出View執行后的HTML，輸出在適當的位置。這樣，使用Server.Execute()方法調用DocumentTransform的aspx頁面后，就是完整的發向客戶端的HTML了。 其實Transform是考慮了頁面的整體布局，一個View只會對某個區域負責的狀況，但是它并不支持復雜的布局，只能說是輕量級吧。復雜的布局通過iFrame等實現，或者做些修改后結合Ajax方式進行局部更新。 2.6 MaverickContext 這是一個上下文對象，主要負責在Command、Controller、View之間傳遞信息。它包含HttpContext、Model和一個IDictionary類型的Params屬性。 HttpContext對象在創建MaverickContext時由創建者（Dispatcher或者ControllablePage）提供；Model由Controller執行處理時創建；Params用于在需要的傳遞其它的參數。 從MVC的角度來看處理流程，如下圖： 3. 簡評 在其它一些介紹Maverick.Net的文章里，有看到不少對Maverick.Net，對ASP.Net下如何運用MVC概念的討論，看法各不一樣。其實對.Net下的開發、架構設計的運用，本來都是仁者見仁，智者見智的事情，只是看大家怎么運用了。下面的這些感想，只是針對企業級應用的架構模式方面，對基于快速開發的小型項目當然另當別論。 3.1 M－V－C分離 ASP.Net本身的確就是一種MVC的框架，可以說是一個很強大又很好用的MVC框架，但是有一些障礙在阻撓著我們。ASP.Net本身的許多特性，使得M-V-C之間的概念變得模糊甚至混亂。 看一下這個場景：添加一個Web Form；用Drag-Drop方式在Form中添加GridView、Connection等數據庫組建；設置相應的屬性，例如數據庫連接，GridView的數據源綁定等。可能就簡簡單單1、2行代碼甚至1行都不需要，運行這個Web Form就將數據顯示出來了。一切是這么方便和簡單，給BS開發帶來一種革命性的思想。可是基于企業級應用架構層面來看，從這樣的場景中你能得到什么，想到什么？ 當然，對富于經驗的人，這根本就不是問題所在。隨便寫一段代碼，就能很好的體現MVC的思想，無所謂使用的哪種語言，什么工具。假如現在需要幾百個開發者協同完成一個項目，情況會怎樣？ASP.Net本身在架構方面沒有太多約束力，盡管它是一個很好的MVC框架。而這種情況下，又非常的需要在架構上對協作的開發者進行約束、規范，否則怎樣確保按照架構、設計方案進行開發，就是件災難性的事情。 Maverick.Net在MVC的呈現上是非常清晰的。也許你會發現，在你的架構中正是需要引入這樣的一種思想。不管是哪個子團隊，哪一個人，使用這一個框架，就需要理解它的思想，按照它的規范進行開發。 3.2 分析設計思想的轉變 MDA 從大的視角來看，用戶需求與軟件系統之間的邊界，就是UI表現層的東西，也就是View。一套系統最終都是通過View向用戶，或者是通過接口向其它系統，呈現出它的全部內容。系統開發是對需求的實現，而架構設計則是對需求的抽象。 在小型項目中，可以不需要什么方法論。把握了需求之后，就著重在表現層的設計，與用戶確認好之后，以這個為目標把系統開發出來就OK了。這是很直接的一種方式，也是人的思維模式中比較容易接受的一種方式。在企業級應用的架構中，如果在不同程度上以這種方式驅動，或多或少的以表現層為主體，就會妨礙我們的抽象行為，也就是影響到架構的質量。 MDA的思想中，強調的是先從需求中提取Business Model，然后以Model為主體，對業務邏輯進行分析。在框架層面將M-V-C比較清晰的區分開來，有利于在分析設計思想方面向MDA方式的轉換。 3.3 簡單，而又強大的框架 忘了是在哪里看到的這樣一句話。說它簡單，因為整個Maverick.Net項目的代碼很少，用于實現的主要對象也不多，它僅僅用一個框架性的協議把M－V－C之間作分離，對Model、View、Controller方面并不做任何過多的擴展、處理。所有關于View的呈現方面、Controller的架構方面等，完全交由使用者自行決定。說它強大，因為整個框架的可擴展性相當不錯。 但并不是說這么好的一個框架，拿過來用就是了。說它好，可能很大程度上是在指它的思想層面，并不能代表它目前的實現就是最好的或者說非常合理的。隨便列舉幾點： a) 有考慮多語言的方案，但是沒有實現。 b) 它的Controller是基于類的層面配置，這個該如何使用？ 方案1：把它的Controller當作Business Facade，所以可能需要為每個Command寫一個Controller類，用這個類去整合與Business Model相對應的各個Business Rule類。這種方案有利于分布式、SOA的運用，但是每個Command開發個Controller顯得有點繁瑣。 方案2：把Controller作為完整的Business Logic封裝，在上下文中使用參數等其它機制，將Command關聯到Controller的方法層面上。 c) Controller + View類型的選擇 方案1：使用aspx類型的Controller。這種方式的優點在于能夠使用ASP.Net的機制，包括常規的PostBack事件機制、用戶控件等，或者整合ASP.Net其它一些東西，例如Atlas等，可能都會比較方便。但以我個人的觀點來看，不提倡將*.aspx.cs作為Controller，而是純粹的作為View的一部分。*.aspx.cs只負責利用ASP.Net的機制，從頁面獲取參數、創建Model對象傳遞給控制類；在從控制類重新得到Model等相關信息之后（Controller處理完畢的結果），再利用ASP.Net機制將這些信息進行呈現。 當然，將*.aspx.cs作為輕量級的Business Facade也是可以考慮的方案。 方案2：使用xml或者Maverick.Net標準的document方式。 其實這兩種方式之間的差別還是很大的。使用xml方式的話，將使用XsltTransform進行轉換，可能需要編寫大量的xslt文件。使用Maverick.Net標準的document方式，是指完全類似ASP的方式了，使用DocumentTransform進行轉換。這兩種方式都是使用Maverick.Net的典型工作方式，即以.m作為請求頁面的后綴，由Dispatcher對HttpRequest進行處理。在頁面編寫時，它們都不能使用ASP.Net特性了，說這種方式下完全拋棄了ASP.Net機制也不過分。所以對于ASP.Net開發者將它們視為同一種方式也不奇怪了。 直接使用這種方式開發，可能沒有多少人能夠接受。但是基于這種方式，在View的開發方面下一些功夫，例如封裝、通用化模板的擴展、添加適用于Maverick.Net的Ajax方案等，是能夠在一定程度上降低這種方式下View開發的繁瑣性，達到基本可以接受的程度（相對于ASP.Net開發者而言）。

??? 2006-09-11：補充一副圖

Maverick.Net代碼解析

相關概念、總體處理流程參考Maverick.Net介紹篇，不再羅嗦。一看就懂的地方略，側重在貌似疑難之處及部分過程的分析。本人水平一般，如有不正確的地方歡迎指正。 Dispatcher 職責：一，HttpHandler，處理Http請求，包括Http Request-Command的映射、Command對象的管理；二，負責對初始化操作的管理。 ExtractCommandName(HttpContext context) 將類似welcome.m的虛擬請求文件名的.m后綴去掉，取welcome作為Command的名稱。這個名稱與maverick.config配置中command節點的name屬性相對應。 LoadConfigDocument(HttpContext context) 初始化操作函數之一，讀取maverick.config配置文件，返回XmlDocument對象。 其中有一個轉換處理，讀取maverick.config的xml之后，使用一個xsl文件進行轉換，返回轉換之后的XmlDocument對象。可以這樣來理解，Maverick.Net已經確定了配置文件maverick.config的格式，但你可能不是使用這個格式，例如你對Maverick.Net做了擴展，可能也會相應的調整maverick.config格式，等等情況之下你可以用一個xsl將maverick.config配置轉換成Maverick.Net要求的格式。 ReloadConfig(HttpContext context) 初始化操作函數之一。 a) 創建Loader對象。Loader創建過程中將創建Command Factory、View Factory、Transform Factory這一系列工廠，并利用這些工廠，根據maverick.config的配置創建所有的Command、View、Transform對象。 b) 對forward類型View的檢查。Maverick.Net介紹篇中提到過，forward類型的View是重定向到另外一個Command。這段檢查代碼就是遍歷所有Command下面的View，確保forward類型的View重定向的目標Command是存在的。 c) 創建兩個特殊的Command并添加到Command集合中。關于這兩個特殊Command的說明參考Maverick.Net介紹篇。 Init() 初始化操作的入口函數。
??? Maverick.Net將Dispatcher的IsReusable屬性返回true，因此IIS將使用Application Pool重用這個HttpHandler（參考HttpHandler相關文檔）。但注意：重用并不是說Init()函數對整個應用而言只會執行一次，IIS在并發處理多個Http Request時，會為每個請求分配一個Http Handler對象（Dispather），每一個Dispather實例將執行一次Init()操作。
ProcessRequest(HttpContext context) IHttpHandler接口方法，參考MSDN文檔。 創建MaverickContext對象時，先嘗試從HttpContext.Items中獲取，是因為如果將多個Commands配置成一個鏈（Chain）來處理某個Http Request（就是Action Flow的概念，不過Maverick.Net是在前端控制器－Front Controller上實現這個，直覺上看跟View的關系太緊密，有遠離Business Logical/Workflow的感覺，但確實是一個Action Flow），需要使用同一個MaverickContext對象，用于Chain中的各個Command之間協作時傳遞Model等數據消息。這個Chain中的第一個Command會把MaverickContext對象放入HttpContext.Items中，隨后的Command都是從HttpContext.Items中獲取。Chain中的Command如何傳遞數據消息？Chain中某個Command處理時，可能會更新、處理Model信息，還可以向MaverickContext中添加特定的參數，接下來的Command就可以從MaverickContext獲取更新處理之后的Model和這些特定的參數。
??? ICommand GetCommand(string name)
??? 名稱為*的Command被用作一個特殊的Command，即當Dispatcher接收到一個無效的Command時，將使用名稱為*的Command來處理。我們在使用Maverick.Net框架時可以實現這個Command，用于提示用戶無效的操作信息。否則將產生一個404的異常。 其它 a) Command大小寫敏感選項：處理Command在大小寫敏感方面的問題。首先Command對象用Hash Table緩存，使用Command Name的Key值進行索引時存在大小寫敏感問題。Command Name通過HttpRequest.ApplicationPath解析出來，某些系統中可能會自動將ApplicationPath轉換成大寫。因此提供這個功能用于解決大小寫敏感問題。 b) 兩個特殊的Command：ReloadCommand、CurrentConfigCommand參考Maverick.Net介紹篇。 c) 關于Dispatcher線程安全方面。詳細的HttpHandler線程安全方面話題，請參考其它相關資料。 第一點，在初始化的一系列操作中，我們可以看到很多地方將HttpContext對象作為參數傳給工廠類，而在Command、View、Transform等執行時刻（函數Go()）也用到HttpContext對象，是否會存在線程安全問題？其實在各個工廠類中，以及Command、View、Transform等對象創建時刻，如果使用到HttpContext內容，只是用于獲取ApplicationPath等對于整個應用而言全局的數據信息，這在每個Http Request期間都是相同的；而Command、View、Transform等執行時刻使用到的HttpContext對象，都是從MaverickContext中獲取，在Dispatcher處理每個Http Request時都會使用當前請求的HttpContext創建一個新的MaverickContext（將Command配置成Chain方式除外）對象。因此對HttpContext的使用上，Maverick.Net不會有線程安全方面的問題。 第二點，ReloadCommand和CurrentConfigCommand這兩個特殊Command是非線程安全的。Init()函數說明中提到過，雖然Dispatcher對象是可復用的，但在Application Pool中可能會有多個Dispatcher的實例。當提交一個ReloadCommand時，會從Application Pool中取一個實例用于服務這個請求，因此這個Dispatcher實例會根據當前的maverick.config配置重新進行初始化，但這個初始化不會影響Application Pool中的其它實例，其它實例使用的仍然是根據舊的maverick.config創建的對象。 其實它是違反了HttpHandler的一個線程安全規則：不要使用成員變量或類似的機制，用于不同的請求、線程間保存傳遞狀態、數據信息。這種情況下可以用一個類似Observer模式解決，或者對Dispatcher使用成員變量保存Command對象集合的方式做修改。

• 初始化、工廠類部分

這部分類圖如下： 圖一：初始化、工廠部分類圖 Maverick.Net實現了2種類型的Transform和6種類型的View，每種類型的Transform和View都對應到一個工廠類，負責創建特定類型的實例。實際的Transform、View的創建操作，永遠都是由該類型的Transform、View對應的工廠對象完成的。 MasterFactory負責管理全部的Transform、View的工廠（分別用兩個HashTable成員保存），并聚合了Transform、View的創建方法。因此，當需要創建Transform或View對象時，調用MasterFactory.CreateView()或者MasterFactory.CreateTransform()，將請求提交給MasterFactory對象。MasterFactory負責根據Transform、View的類型，找到對應的工廠對象，然后調用工廠創建Transform或View。 ViewRegistry主要負責Global View的注冊，以供隨時取用Global View對象；以及對全局View的引用問題（就是CreateViewsMap方法中的處理）。ViewRegistry保存了一個MasterFactory的對象，當要創建一個View時，通過調用MasterFactory的方法完成。 關于Shunted View相關概念后面介紹。 Loader負責對全部創建工作的管理。經過上面類職責的了解可以知道，其實Loader只需要管理好CommandFactory、MasterFactory、ViewRegistry這三個類就達到目的了。Loader在構造函數中完成初始化操作，所以Dispatcher只需要創建Loader對象，從Loader獲取創建的Command集合就行。 Loader 初始化的執行過程大致如下圖所述： Loader(XmlDocument doc, HttpContext httpContext) 構造函數，完成全部初始化操作。 創建Command的容器HashTable時，將根據Command大小寫敏感配置分別進行處理。 SetupCoreModules() 分別創建各種類型的Transform Factory、View Factory，調用這些工廠的初始化方法，將工廠對象注冊到viewFactories、transformFactories這兩個HashTable成員中。 工廠的初始化方法給工廠對象提供一個初始化自己的機會，但是現有的一些Transform、View的工廠中，絕大部分初始化方法都不做什么實質性的事情。 LoadDocument(doc) 在調用這個方法之前，各類工廠對象均已經被創建并完成初始化操作，這個方法就是利用這些工廠對象，根據maverick.config配置文件的XmlDocument對象（doc），創建各個框架對象。 LoadModules(XmlElement modulesNode)
??? 這個函數根據maverick.config文件的配置，創建自定義的Transform、View工廠對象，以及自定義的ShuntFactory。 這是為擴展Transform、View的類型，以及實現ShuntView提供的一種途徑。假如需要擴展一種新的View類型，就需要為這個View類型實現一個工廠類，將這個工廠配置到maverick.config文件中，這樣在初始化的時候將創建這個工廠對象并注冊到MasterFactory的Transform工廠集合和View工廠集合中。如果需要創建這類型的Transform或View，將使用到這些工廠對象。 Modules節點配置示例如下：? <modules>
??<transform-factory?type="mytran"?provider="mytran.mytranFactory,?mytran"?>
????<default-key-name?value="mytran"?/>
??</transform-factory>
???<view-factory?type="myview"?provider="myview.myviewFactory,?myview">
?????<default-key-name?value="myview"?/>
???</view-factory>
</modules> MasterFactory CreatePlainView(XmlElement viewNode) 讀取View的類型屬性，根據類型值取對應的工廠，使用工廠創建這種類型的View對象并返回。Plain View這個單詞意指簡單的View，即直接由對應的工廠創建出來的View對象。 CreateView(XmlElement viewNode) 使用CreatePlainView函數得到IView對象之后，再根據這個View是否有配置Transform、參數節點，相應的將對象創建成ViewWithTransforms、ViewWithParams類型，以便在View的執行時刻（View對象的Go()方法內）能處理Transform操作和參數。 CreatePlainTransform、CreateTransform 跟上面兩個方法完全類似。 ViewRegistry、ViewRegistrySimple、ViewRegistryShunted 這三個類的關系從圖一：初始化、工廠部分類圖中可以看出來。 在maverci.config文件中，Command節點下面的View節點可以這樣配置：<view name="loginRequired" ref="loginForm"/>，意思是將從全局View中引用id為loginForm的View對象。 這個引用關系并不是在執行時刻處理的，而是在Maverick.Net初始化過程中完成。執行時刻處理可以這樣描述：如果Command根據Controller執行結果，發現需要執行名稱為loginRequired的View，而這個View是對Global View中id為loginForm對象的引用，所以從Global View中檢索出這個loginForm的View對象，然后執行它。這樣的處理方式，給框架帶來復雜和不規范性，而把這個操作放在初始化中，則所有View的執行處理就統一起來了。Command對象聚合了一個或多個View對象，在為Command創建聚合的View或View對象集合時，如果某個View是對Global View對象的引用，則從Global View中檢索到這個View對象，直接返回給Command，避免Command在執行時刻從Global View中檢索。這就是CreateViewsMap函數的作用。 Global View的創建是在創建Command之前完成的，確保了在Command創建時刻能夠引用到Global View對象。Global View的引用關系在初始化時刻已經被處理掉，因此ViewRegistry、ViewRegistrySimple、ViewRegistryShunted這三個類也只在初始化的過程中用到，在Maverick.Net正常的處理Http Request期間已經不再需要使用。 ViewRegistryShunted類用于在完成上述功能時，對Shunted View特殊處理的支持。

• Command?????

Command承擔的工作很簡單：執行Controller的處理，根據返回的結果，選擇對應的View，運行這個View。 Command分為兩類，一類是沒有Controller的，對應CommandSingleView。這類Command不需要根據Controller的執行結果選擇View，因此，這類Command有且只能有一個View，Command的執行其實就是直接對這個View進行呈現。Maverick.Net對這類Command使用一個NullController，這個Controller不做任何事情，只是為了保持Command行為的一致性。 另一類是有Controller的，對應CommandMultipleViews。在初始化創建Command實例時，已經為Command創建了Controller對象，因此Command只需要調用這個Controller對象的Go()方法執行處理。 CommandBase提供了Command規范性的處理。CommandSingleView和CommandMultipleViews繼承CommandBase，主要實現GetView方法，即怎樣從Command對象持有的View對象中選擇正確地View來執行。

• View

幾個簡單的View。 NullView：不做任何事情。可以用于Command節點下面沒有配置任何View的情況，但Maverick.Net目前沒有這樣使用，如果Command下面沒有View節點將產生異常。 TrivalView：將Model以字符串的方式直接輸出。如果某個Http請求的結果，只是一段文本消息，或者是輸出一個文本文件、xml文件內容等，可以使用這種類型的View。 ForwardView、RedirectView：功能上基本是一樣的。 ForwardView重定向到另外一個Command。它是直接在View的執行時刻，使用Dispatcher獲取Command對象，調用Command.Go()方法。假如某個View需要重定向到名稱為login的Command，View節點配置為：<view name="viewName" command="login"/>。 RedirectView使用Response.Redirect()方法進行重定向，所以重定向的目標可以是某個asp/aspx頁面也可以是某個Command。假如需要重定向到名稱為login的Command，RedirectView的實現方式為Response.Redirect("login.m")，這種情況下可以將ForwardView看作是RedirectView的一種特例。RedirectView更傾向于重定向到某一個asp/aspx頁面，因為這類型的View在重定向之前，會將需要傳遞的參數，以GET的方式拼寫到url中，參數將包括IDictionary類型的Model對象和MaverickContext.Params。如果Model對象是String類型，則RedirectView將把Model當作目標url，而忽略view節點中配置的url。這類型的view配置示例如：<view name="viewName1" path="login.m"/>、<view name="viewName2" path="default.aspx"/>。 如果整個項目以Maverick.Net架構，是不需要使用RedirectView重定向到另外的asp/aspx頁面的，提供這種類型，有利于與其它項目進行基于頁面層次的整合，或者類似的用途。 DocumentView：這個View類型復雜些。 在類圖結構中，最基礎的是DispatchedView，這個類型的View完成asp/aspx等類型的頁面文件轉換成HTML的操作，它是internal的類型，只在框架內部使用，實現的也是document類型View最基礎的功能。 DocumentView聚合一個DispatchedView對象，因此擁有DispatchedView的功能，派生DocumentView主要是解決Model存放位置問題。它為abstract類型，通過abstract類型的方法SetAttribute提供給子類解決如何傳遞Model。 ApplicationDocumentView、SessionDocumentView、RequestDocumentView都繼承自DocumentView，實現自己的SetAttribute方法，分別使用Application、Session、HttpContext.Items作為存放Model的地方。Type為document類型的View，在配置節點中通過scope屬性確定該View屬于這三種類型中的哪一種，如果沒有聲明scope屬性，默認為RequestDocumentView類型。 以一個RequestDocumentView類型的對象來看，在調用這個view的Go()方法的時候，先在DocumentView.Go()方法處判斷，如果Model對象不為null，則執行RequestDocumentView.SetAttribute()方法，將Model放入HttpContext.Items中。這樣，這個view對應的aspx頁面的服務器端代碼，就應當從HttpContext.Items中獲取Model對象進行顯示。接下來將調用聚合的DispatchedView對象的Go()方法，將這個aspx頁面解析成HTML。 XmlSerializingView：單純的從View的功能上看，它也非常簡單，就是將Model反序列化之后的xml直接輸出。這類型的View大都用于基于xml的網站方案中，將Model序列化成xml之后，可以使用XsltTransform將其轉換成HTML。 以上介紹的幾個類型的View的實例都由相應的View Factory創建，可以說是一種簡單類型的View對象。它們實現了幾種基本形態View的功能，Document類型的View復雜一點，在View的顯示過程中將使用到Model對象，所以Document類型的View在類的結構上看起來也復雜一些。 剩下的兩種類型的View就當作擴展類型來看待吧。 ViewWithParams：有時候我們可能希望為某些View配置一些特殊的參數，例如有兩個功能，Web頁面98%都是相同的，僅有微小的一點區別，我們可能會希望只寫一個頁面，通過給它們不同的參數，使這一個頁面運用在兩個功能中。ViewWithParams聚合了一個IView對象，它在本身的Go()函數中附加一些對參數的處理，即將參數保存到MaverickContext這個上下文對象中，然后再調用聚合IView對象的Go()方法。這樣，被ViewWithParams封裝過的IView對象或者是對應的aspx頁面中，就能通過MaverickContext訪問到這些參數。 參數的配置示例如下： <view?name="UserView"?path="UserView.aspx">
??<param?name="param1"?value="???"?/>
??<param?name="param2"?value="???"?/>
</view> 因為這種類型的View只是對基礎類型View的一個封裝擴展，并且也許會有多個類型的View希望能夠使用參數，復用這樣一個功能特性，所以Maverick.Net并沒有把這種封裝過程放入到具體的某一個ViewFactory中，而是放在了MasterFactory中處理。在MasterFactory.CreateView(XmlElement viewNode)方法中可以看到這一處理。 ViewWithTransforms：這類型的View聚合一個IView和多個ITransform對象，用于在View執行時對Transform處理。跟ViewWithParams類似，用ViewWithTransforms封裝IView對象的操作也是在MastrerFactory中處理。在Maverick.Net中，雖然從表面上看起來View和Transform的銜接很緊密，但Maverick.Net對View和Transform采用一種較松散的耦合方式來處理。 在現有的View類型中，只有基于DocumentView類型的以及XmlSerializingView類型才能使用Transform操作。 ViewWithTransforms.Go()方法先將Transforms對象放入MaverickContext中，然后調用聚合的IView對象的Go()方法。聚合的IView對象為DocumentView或XmlSerializingView類型，對于DocumentView類型的將調用DispatchedView.Go()方法，在DispatchedView.Go()和XmlSerializingView.Go()方法中，都會通過MaverickContext.NextStep對象間接使用到Transform對象，逐步完成輸出內容的轉換。 以一個DocumentView對象、具有一個Transform配置節點作為示例，看一下Transform的處理過程。 每一個Transform對象都由位于它前面的一個驅動對象創建一個ITransformStep，用于執行轉換操作。第一個Transform的ITransformStep由DispatcheView創建。 DispatcheView執行時，先使用第一個Transform對象創建ITransformStep，使用Server.Execute()將DispatcheView的aspx頁面轉換成HTML，放入ITransformStep創建的MemoryStream中，然后調用ITransformStep的Go()方法。隨后的每一個ITransformStep在Go()方法中，首先使用下一個Transform對象創建下一個ITransformStep，然后從MemoryStream讀取上一個驅動對象放入的HTML，用它對應的Transform配置節點中的key屬性值作為Key值，將HTML放入HttpContext.Items中，最后使用Server.Execute()方法，執行它對應的Transform對象的aspx頁面，將輸出的HTML放入下一個ITransformStep的MemoryStream。 當執行達到最后一個Transform位置時，它后面再沒有其它Transform，因此創建LastStep類型的ITransformStep對象，這個對象的Go()方法是一個空操作，但是它將HttpContext.Response.OutputStream作為MemoryStream的替代，因此，最后一個Transform的aspx頁面在使用Server.Execute()方法執行后，就直接輸出到Response.OutputStream中了。 理解上面的處理過程之后，會有一個疑問，就是只看到了最后一個Transform對應的aspx執行后的HTML代碼發送給客戶端，它之前的Transform對應的aspx頁面、View對應的aspx頁面執行后的HTML代碼呢？從這個過程中我們只能看到這些HTML代碼被依次放入HttpContext.Items中，并沒有看到向客戶端輸出。實際上，從Maverick.Net的示例項目Friendbook中，取一個View最后一個Transform相關聯的aspx頁面看一下就知道了，在這個aspx頁面里，會看到類似<%=Context.Items["wrapped"]%>的服務器端語句，就是這個語句從Context.Items中取出一段HTML內容并輸出。這樣就可以明白了，最后一個Transform對應的aspx頁面執行后的HTML代碼，自然就包括了它前面的Transform、View執行后的HTML。 View對象本身的關系可能會有點復雜，例如可能創建的一個ViewWithTransforms對象，將會聚合一個RequestDocumentView，而這個RequestDocumentView又聚合一個DispathedView。另外，在View的執行時刻，跟Transform的轉換結合在一起。所以，一個IView對象的Go()方法，感覺上轉來轉去，使對這個處理過程的理解產生疑惑。通過上面的描述，好好的理解這些對象的職責，把它們的關系梳理清楚之后，你會發現其實還是很簡單的。 ShuntedView 整體上來看，ShuntedView也是比較簡單的。普通類型的View，通過一個name屬性作為Key值，ShuntedView則必須使用name屬性加上一個mode屬性一起才能作為Key值。這是用于實現多語言之用，比如同一個View UserQuery，可能需要有中文、英文等語言支持，將語言代碼作為Mode，使用UserQuery + ch獲取中文版本，使用UserQuery + en獲取英文版本。相應的，View的配置節點類似如下： <command?name="UserQuery">
????<controller?class=""?/>
????<view?name="loginRequired"?ref="loginRequired"/>
????<view?name="success"?type="document"?path="UserQuery-ch.aspx"?mode="ch">
????????<transform?path=""/>
????</view>
????<view?name="success"?type="document"?path="UserQuery-en.aspx"?mode="en">
????????<transform?path=""/>
????</view>
</command> Maverick.Net在多語言的實現方式上并不理想。一個View，如果對應于每一個語言都需要寫另外一個頁面，這種方式只能說太笨了。這種情況下，如果View需要修改，任何時候都將需要對不同語言版本的頁面同時修改。 下面這副圖幫助理解一下Shunt處理過程。 目前Maverick.Net并沒有使用ShuntedView，在Loader的構造函數中，創建的是ViewRegistrySimple而不是ViewRegistryShunted對象。如果使用多語言，應當在這個地方使用ViewRegistryShunted，上面的圖就是基于這種情況下的處理過程描述。 具體的實現細節根據這個序列從代碼上可以看出來，下面講的是大致的思路。ViewShunted僅僅是聚合一個IShunt對象，并實現IView接口，真正的操作是由IShunt對象完成的。在多語言的運用情況下，IShunt對象為LanguageShunt類型，這個類型的對象維護了一個HashTable成員modes，它以View配置節點的mode值作為Key，將name相同而mode值不同的多個IView對象保存在這個HashTable中。這樣，name相同而語言版本不同的多個IView對象，通過ViewShunted的封裝，從外部看起來它就成為一個IView對象了。在上面的xml示例配置中，名稱為UserQuery的ICommand對象，將擁有兩個（注意不是三個）IView對象，一個為loginRequired，另外一個為ShuntedView類型的success。這樣對于ICommand對象執行時，對ShuntedView的處理方式上也是規范的，ICommand對象無需了解后面的細節。ViewShunted類型的View在執行時，嘗試從Request.Headers對象中取語言代碼，然后根據這個語言代碼獲得對應的IView對象，繼而調用這個IView對象的執行方法。

• Transform

其實經過上面對ViewWithTransforms執行過程的理解，對于Transform對象也就沒有什么懸念了。 盡管DocumentTransform在概念上理解起來比較牽強，因為view的aspx執行之后就是HTML了，感覺上不再需要什么轉換處理，Maverick.Net的示例項目Friendbook中將Transform作為幾乎所有工作頁面的一個整體包裝頁面的用途。也許你還能發現其它有意思的用處。 對于基于xml的網站，XsltTransform的作用理解起來就非常直接了。對XsltTransform，有幾種方式的用法： 1. 將View配置成document類型，用path直接指定一個靜態xml文件，然后使用xsl解析。例如
<view?type="document"?path="welcome.xml">
??<transform?path="outside.xsl"/>
</view> 2. 將View配置程xml（XmlSerializingView）類型，把Model反序列化成xml，使用xsl解析。 3. 將View配置程trivial類型，由Controller直接構造xml，然后用xsl解析。 4. 將View配置成xml類型，View并不輸出任何xml，直接使用Transform處理。這種情況通常第一個Transform輸出xml，后面的Transform解析成HTML。這種跟1基本完全一樣。 對xml類型的View使用XsltTransform轉換的處理過程，跟DocumentTransform完全一樣。 在這個處理的Chain上，IView對象是起點。前面提到過，View跟Transform之間是一種較松散的耦合方式，這樣，IView對象無需去管理自己有多少個Transform，應該怎樣一步一步的執行轉換，以及將最終的結果發送給客戶端。IView對象只需要完成自己的職責，它知道在它的后面一定有其它的對象來處理上面這些事情，所以IView處理完之后，將它輸出的視圖代碼拋給下一個對象即可。 LastStep對象是Chain的終結者，負責將最后的輸出發送給客戶端瀏覽器。 大概考慮到無論是Server.Execute()或者System.Xml.Xsl.XsltTransform.Transform()方法都可以向Stream直接輸出，Maverick.Net在Chain處理上，采用一個Stream類型的成員變量向后傳遞輸出內容。既然這樣，在Chain上每一個執行步驟中動態創建一個ITransformStep就成為一種必要。

• Controller?

Maverick.Net提供一些Controller的基礎類，用于實現不同用途下的Controller。
??? ......

posted

?MAVERICK.NET初窺

ASP.NET出來了很久了，微軟一直強調其ASP.NET是給WEB開發帶來了很多的方便，code-behind的方式優化了代碼的結構，等云云。然而當我們真正用ASP.NET來開發時，我們發現我們還是陷入到了混亂之中，如：

• MVC如何實現（雖然code-behind從某種意義上說是實現了C和V的分離，但是還是遠遠不夠）
• 頁面間的flow如何處理（還是在代碼中采用了hard-code的方法，要修改頁面的跳轉，必須修改源代碼，頁面間的關系不能清楚地表現和可配置）
• 多語言怎么實現（雖然可以用資源文件來解決，但是一個單詞的中文和英文的長度不一致，很多時候還是要重寫2個頁面，根據不同的瀏覽器多語言配置如何實現這些不同頁面的選擇，也不能很好解決）
• 公用頁面模塊如何盡量提高可復用性（雖然微軟也提供了User Control，但是它始終和ASPX有很多不一樣，很難對2者共同對待）
• 等

微軟也意識到了這些問題，于是出了個UIPB，但是UIPB也僅僅解決了一小部分的問題，如前面所說的頁面跳轉的問題。坦白地說，我認為UIPB的設計初衷實在是一個錯誤的方向。UIPB主要解決一個項目WEB表現層和WINFORM表現層如何能夠最大范圍的復用的問題。試問有多少項目會有這樣的需求？誠然有些項目確實需求2種表現層，但是也是各自完成不同的任務居多。即使是有這種需求，我們也知道WINFORM和WEB有太多的不同，有些WEB中多個頁面跳轉完成的事情，在WINFORM中僅僅是一個窗口就可以完成。另外WEB中要盡量少用彈出窗口，而WINFORM沒有這種限制。因此我認為UIPB還是沒有解決WEB層的大多數問題，不能適應現在商業的WEB項目開發。

那么我真的開始苦惱了，.NET項目中應該用什么來實現表現層？看看J2EE陣營，他們確實也苦惱，但他們苦惱的是面對那么多的開源解決方案應該選擇那個。有的時候真想改姓J2EE算了，呵呵。

終于前些天看到了MAVERICK.NET項目，實際上這個項目也是從J2EE的MAVERICK項目port過來的。我把Maverick.NET當了下來，研究了幾天，總算心理稍稍平了點。從我現在對MAVERICK.NET的淺薄的了解中，我認為它至少解決了以下幾個問題：

• 完全的MVC實現
• 頁面間的跳轉問題可以通過一個統一的配置文件建立期間的聯系
• 頁面模塊可以靈活地通過配置文件plug到多個View中去
• 多語言的幽雅實現
• 頁面的模板可以使用XSLT等轉換技術

下面我從MAVERICK.NET中自帶的一個簡單例子來簡單說明：

配置IIS，將.m的文件用ASP.NET引擎來解析

配置web.config，加入以下語句：
<configSections>
??? <sectionGroup name="Maverick">
??????? <section name="Dispatcher" type="System.Configuration.NameValueSectionHandler,system, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, Custom=null" />
??? </sectionGroup>
</configSections>

<Maverick>
??? <Dispatcher>
??????? <add key="configFile" value="maverick.config" />
??????? <add key="currentConfigCommand" value="currentConfig" />
??????? <add key="reloadCommand" value="reload" />
??????? <add key="limitTransformsParam" value="maxTransforms" />
??????? <add key="commandCaseSensitivity" value="insensitive" />
??? </Dispatcher>
</Maverick>

?</system.web>???????
??? <httpHandlers>
??????? <!-- 該工程的任何頁面訪問都會首先執行該httpHandler，實際上是一個dispatcher，
??????????? 來根據maverick.config的配置來啟動相關頁面 -->
??????? <add verb="*" path="*.m" type="Maverick.Dispatcher, Maverick" />
????</httpHandlers>
?</system.web>

配置maverick.config文件
<maverick version="2.0" default-view-type="document" default-transform-type="document">
??? <commands>
??????? <command name="Default.aspx">
??????????? <view name="success" type="trivial">
??????????????? <transform path="~/Wrapper.aspx"/>??? <!-- 這就是一個標題，也就是嵌入的公用頁面模塊 -->
??????????? </view>
??????????? <view name="april" path="~/April.aspx">
??????????????? <transform path="~/Wrapper.aspx"/>
??????????? </view>???
??????????? <view name="button" path="~/Button.aspx">
??????????????? <transform path="~/Wrapper.aspx"/>
??????????? </view>
??????? </command>
??? </commands>
</maverick>
　

建立Default.aspx文件，在code-behind文件中添加一個以下方法
protected string viewName = "success"; // 默認顯示名為“success”的view
public override string Go(Maverick.Flow.IControllerContext cctx)
{
??? return this.viewName;
}

在一個button的時間代碼中添加如下代碼，當button按下時，就會根據maverick.config的配置來顯示相應內容
private void Button1_Click(object sender, System.EventArgs e)
{
??? this.viewName = "button"; //按下button后就會顯示名為button的view
}

在一個日歷控健的Selection_change事件代碼中，添加如下代碼
private void Calendar1_SelectionChanged(object sender, System.EventArgs e)
{
??? if (this.Calendar1.SelectedDate.Month == 4)
??????? this.viewName = "april";??? // 當該代碼執行時，就會轉向名為april的view
}
　

建立April.aspx、Button.aspx、Wrapper.aspx頁面

以上的例子至少體現了，Maverick的頁面跳轉配置實現、公用頁面模塊靈活配置的2個優點，因為這是一個最簡單的實現，所以其他的特點沒有完全展現。關于MAVERICK.NET的應用、以及under the hook，我將在后續的post中描述。

轉載于:https://www.cnblogs.com/lsgoodsun/archive/2007/08/13/854172.html

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的Maverick.Net介绍 (来自http://www.cnblogs.com/RicCC/archive/2006/09/17/506890.html)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。