ASP.NET上的另一個MVC實(shí)現(xiàn)：FubuMVC
在ASP.NET MVC 正式版發(fā)布前，Jeremy D.Miller 和Chad Myers 就在ASP.NET MVC的早期版本上進(jìn)行了一些工作，并對底層實(shí)現(xiàn)做了一些修改。后來他們改掉了幾乎所有的ASP.NET MVC實(shí)現(xiàn)，于是決定構(gòu)造另一個MVC實(shí)現(xiàn)FubuMVC ，不久后Mark Nijhof 被邀請加入項(xiàng)目并成為主要成員。
Fubu代表“For us，by us”?，F(xiàn)在FubuMVC除了使用ASP.NET Routing外，不使用任何ASP.NET MVC的實(shí)現(xiàn)代碼，而ASP.NET Routing則已經(jīng)包含在.NET Framework 3.5 SP1中。
Jon Arild Tørresda詢問了Chad Myers，ASP.NET MVC與FubuMVC之間***的不同是什么：
如果非要選一個，我選擇“組合對繼承”。這是一個設(shè)計上的基本區(qū)別，但并不是說ASP.NET MVC的設(shè)計不好，只是我認(rèn)為ASP.NET MVC在類結(jié)構(gòu)設(shè)計上傾向于使用繼承，因而無法像使用組合那樣易于設(shè)計動態(tài)的Web應(yīng)用程序。
FubuMVC是一個前端控制器 （Front Controller）框架。Chad指出這個模式的兩個主要目標(biāo)是：
◆分離對請求的不同關(guān)注點(diǎn)
◆允許使用組合的方式構(gòu)造響應(yīng)，以發(fā)回給客戶端
對于前端控制器，Chad解釋道：“我們不是不能使用ASP.NET MVC來實(shí)現(xiàn)前端控制器，但是這非常的困難”。
在FubuMVC中有很多實(shí)現(xiàn)方面的決定，其中之一是在Controller的Action執(zhí)行前后所執(zhí)行的“行為”。Chad解釋了為什么他們管它叫行為，以及它在FubuMVC中的意義。
當(dāng)我在一個Virual ALT.NET（VAN)會議上向一些人演示FubuMVC的早期版本時，Steven Harman (http://stevenharman.net）建議我將之稱為“行為”，因?yàn)檫@個詞語準(zhǔn)確描述了所發(fā)生的事，我有點(diǎn)喜歡這個名字。
在FubuMVC中，行為的實(shí)現(xiàn)方式實(shí)際上是裝飾模式和職責(zé)鏈模式的混合體。
行為對請求管道擁有完全控制權(quán)，它可以添加或修改請求，動態(tài)選擇需要執(zhí)行的action以及是否要執(zhí)行action，它可以修改或者完全替換action的輸出結(jié)果，并且可以在完成請求處理后執(zhí)行一些代碼。實(shí)際上，生成顯示結(jié)果本身也是一個行為。FubuMVC使用行為本身來實(shí)現(xiàn)基本的功能，這些基本功能和行為可以根據(jù)需要被替換或修改。
Mark Nijhof在他的文章FubuMVC and the Front Controller style framework中展示了這個管道：
Chad說，“行為開啟了在其他框架中難以實(shí)現(xiàn)的可能”：
◆將整個請求包裝在try/catch/finally塊中的能力
◆多級緩存的能力
◆根據(jù)運(yùn)行時環(huán)境或請求時間，動態(tài)決定執(zhí)行哪個action的能力
#p#
MVC模式的另一個方面，是使得開發(fā)人員可以對傳統(tǒng)意義上無法進(jìn)行測試的UI部分進(jìn)行單元測試。Chad描述了微軟是如何實(shí)現(xiàn)這一點(diǎn)的：
微軟在最近對MVC框架的更新中（Beta，RC和最終的發(fā)布版）邁出了一大步，相比于Preview 3，對單元測試的支持更好了。但是我仍然認(rèn)為繼承和防備代碼的過度使用以及故意不使用接口，使得在ASP.NET MVC中進(jìn)行測試顯得很笨重。
他繼續(xù)解釋了FubuMVC是如何實(shí)現(xiàn)這一模式的：
相反，F(xiàn)ubuMVC使用簡潔的、易于mock的接口，著重于高內(nèi)聚低耦合的設(shè)計。其中，低耦合更成功一些，但這一切仍在開發(fā)之中，我希望將來的設(shè)計可以提高內(nèi)聚程度。
FubuMVC高度依賴SOLID原則，這使得它有很高的靈活性，開發(fā)人員僅僅使用一個mock就可以替換框架中的整套部件，并且可以使用任何他們喜歡的mock框架。
FubuMVC并沒有很多的防御性代碼……相反，它將注意力集中在設(shè)計提供自由控制的組件上面，這些組建是客戶代碼主要存在的地方：控制器（controller）、行為、視圖（view）以及可以重載的部分。
FubuMVC的類之間幾乎沒有依賴關(guān)系，僅有的依賴也是對接口的依賴，這些接口可以很容易的用mock對象來模擬。
由于項(xiàng)目中有Jeremy（IoC容器StructureMap的創(chuàng)建者），你可能會認(rèn)為控制反轉(zhuǎn)和IoC容器會得到較多的支持，事實(shí)上也確實(shí)如此：
目前的版本僅支持StructureMap，但是將來很可能會加入對其他容器的支持?？蚣軐τ谌萜鞯氖褂梅浅Ｉ?，僅限于在配置時使用。其余的部分利用容器的自動綁定功能完成，因此基本上沒有使用“service location”。對于僅有的一點(diǎn)service location，我們使用微軟Patterns and Practices的Common Service Locator進(jìn)行處理，它可以讓我們方便的替換底層依附于CSL模式的IoC容器（多數(shù)容器都滿足這個條件）。
FubuMVC還有一個contrib project，相比于FubuMVC的核心框架，這個項(xiàng)目的目標(biāo)有什么不同:
我們希望能夠有更多的自由來發(fā)展FubuMVC，因此建立了FubuMVC Contrib。我們想嘗試一下插件，這樣可以有更多的人參與進(jìn)來，他們可以在較少的限制下做更多的嘗試，同時保持核心框架的穩(wěn)定。
FubuMVC核心框架將會維持少數(shù)幾個成員，對待補(bǔ)丁會更謹(jǐn)慎，對框架的修改也會更少。FubuMVC-Contrib將會有更多的參與者、更多的改動、更低的要求，可能有無法工作的代碼或?qū)嶒?yàn)性質(zhì)的代碼。當(dāng)在contrib中開發(fā)出有趣的東西后，可以將這些東西合并到核心框架，或者拆分到單獨(dú)的項(xiàng)目中。
現(xiàn)今，F(xiàn)ubuMVC還沒有ASP.NET MVC那樣成熟，但是它的實(shí)現(xiàn)方式很有趣，這個框架將會如何發(fā)展，它與ASP.NET MVC的發(fā)展方向?qū)性鯓拥牟煌?，我們將拭目以待。關(guān)于FubuMVC的更多信息，可以查看他們的wiki和Ryan Kelley的從頭開始學(xué)FubuMVC教程。
【編輯推薦】
