如何理解ASP.NET MVC實現的FubuMVC

如何理解ASP.NET MVC實現的FubuMVC，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

在ASP.NET MVC 正式版發布前，Jeremy D.Miller 和Chad Myers 就在ASP.NET MVC的早期版本上進行了一些工作，并對底層實現做了一些修改。后來他們改掉了幾乎所有的ASP.NET MVC實現，于是決定構造另一個MVC實現FubuMVC ，不久后Mark Nijhof 被邀請加入項目并成為主要成員。

Fubu代表“For us，by us”。現在FubuMVC除了使用ASP.NET Routing外，不使用任何ASP.NET MVC的實現代碼，而ASP.NET Routing則已經包含在.NET Framework 3.5 SP1中。

Jon Arild Tørresda詢問了Chad Myers，ASP.NET MVC與FubuMVC之間***的不同是什么：

如果非要選一個，我選擇“組合對繼承”。這是一個設計上的基本區別，但并不是說ASP.NET MVC的設計不好，只是我認為ASP.NET MVC在類結構設計上傾向于使用繼承，因而無法像使用組合那樣易于設計動態的Web應用程序。

FubuMVC是一個前端控制器 （Front Controller）框架。Chad指出這個模式的兩個主要目標是：

◆分離對請求的不同關注點

◆允許使用組合的方式構造響應，以發回給客戶端

對于前端控制器，Chad解釋道：“我們不是不能使用ASP.NET MVC來實現前端控制器，但是這非常的困難”。

在FubuMVC中有很多實現方面的決定，其中之一是在Controller的Action執行前后所執行的“行為”。Chad解釋了為什么他們管它叫行為，以及它在FubuMVC中的意義。

當我在一個Virual ALT.NET（VAN)會議上向一些人演示FubuMVC的早期版本時，Steven Harman (http://stevenharman.net）建議我將之稱為“行為”，因為這個詞語準確描述了所發生的事，我有點喜歡這個名字。

在FubuMVC中，行為的實現方式實際上是裝飾模式和職責鏈模式的混合體。

行為對請求管道擁有完全控制權，它可以添加或修改請求，動態選擇需要執行的action以及是否要執行action，它可以修改或者完全替換action的輸出結果，并且可以在完成請求處理后執行一些代碼。實際上，生成顯示結果本身也是一個行為。FubuMVC使用行為本身來實現基本的功能，這些基本功能和行為可以根據需要被替換或修改。

Mark Nijhof在他的文章FubuMVC and the Front Controller style framework中展示了這個管道：

Chad說，“行為開啟了在其他框架中難以實現的可能”：

◆將整個請求包裝在try/catch/finally塊中的能力

◆多級緩存的能力

◆根據運行時環境或請求時間，動態決定執行哪個action的能力

MVC模式的另一個方面，是使得開發人員可以對傳統意義上無法進行測試的UI部分進行單元測試。Chad描述了微軟是如何實現這一點的：

微軟在最近對MVC框架的更新中（Beta，RC和最終的發布版）邁出了一大步，相比于Preview 3，對單元測試的支持更好了。但是我仍然認為繼承和防備代碼的過度使用以及故意不使用接口，使得在ASP.NET MVC中進行測試顯得很笨重。

他繼續解釋了FubuMVC是如何實現這一模式的：

相反，FubuMVC使用簡潔的、易于mock的接口，著重于高內聚低耦合的設計。其中，低耦合更成功一些，但這一切仍在開發之中，我希望將來的設計可以提高內聚程度。

FubuMVC高度依賴SOLID原則，這使得它有很高的靈活性，開發人員僅僅使用一個mock就可以替換框架中的整套部件，并且可以使用任何他們喜歡的mock框架。

FubuMVC并沒有很多的防御性代碼……相反，它將注意力集中在設計提供自由控制的組件上面，這些組建是客戶代碼主要存在的地方：控制器（controller）、行為、視圖（view）以及可以重載的部分。

FubuMVC的類之間幾乎沒有依賴關系，僅有的依賴也是對接口的依賴，這些接口可以很容易的用mock對象來模擬。

由于項目中有Jeremy（IoC容器StructureMap的創建者），你可能會認為控制反轉和IoC容器會得到較多的支持，事實上也確實如此：

目前的版本僅支持StructureMap，但是將來很可能會加入對其他容器的支持。框架對于容器的使用非常少，僅限于在配置時使用。其余的部分利用容器的自動綁定功能完成，因此基本上沒有使用“service location”。對于僅有的一點service location，我們使用微軟Patterns and Practices的Common Service Locator進行處理，它可以讓我們方便的替換底層依附于CSL模式的IoC容器（多數容器都滿足這個條件）。

FubuMVC還有一個contrib project，相比于FubuMVC的核心框架，這個項目的目標有什么不同:

我們希望能夠有更多的自由來發展FubuMVC，因此建立了FubuMVC Contrib。我們想嘗試一下插件，這樣可以有更多的人參與進來，他們可以在較少的限制下做更多的嘗試，同時保持核心框架的穩定。

FubuMVC核心框架將會維持少數幾個成員，對待補丁會更謹慎，對框架的修改也會更少。FubuMVC-Contrib將會有更多的參與者、更多的改動、更低的要求，可能有無法工作的代碼或實驗性質的代碼。當在contrib中開發出有趣的東西后，可以將這些東西合并到核心框架，或者拆分到單獨的項目中。

現今，FubuMVC還沒有ASP.NET MVC那樣成熟，但是它的實現方式很有趣，這個框架將會如何發展，它與ASP.NET MVC的發展方向將會有怎樣的不同，我們將拭目以待。關于FubuMVC的更多信息，可以查看他們的wiki和Ryan Kelley的從頭開始學FubuMVC教程。

關于如何理解ASP.NET MVC實現的FubuMVC問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。