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

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

他繼續(xù)解釋了FubuMVC是如何實現(xiàn)這一模式的：

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

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

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

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

FubuMVC核心框架

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

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

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

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

FubuMVC核心框架將會維持少數(shù)幾個成員，對待補丁會更謹慎，對框架的修改也會更少。FubuMVC-Contrib將會有更多的參與者、更多的改動、更低的要求，可能有無法工作的代碼或?qū)嶒炐再|(zhì)的代碼。當在contrib中開發(fā)出有趣的東西后，可以將這些東西合并到核心框架，或者拆分到單獨的項目中。

現(xiàn)今，F(xiàn)ubuMVC還沒有ASP.NET MVC那樣成熟，但是它的實現(xiàn)方式很有趣，這個框架將會如何發(fā)展，它與ASP.NET MVC的發(fā)展方向?qū)性鯓拥牟煌覀儗⑹媚恳源ｊP于FubuMVC的更多信息，可以查看他們的wiki和Ryan Kelley的從頭開始學FubuMVC教程。

【編輯推薦】

1. 介紹ASP.NET MVC的實現(xiàn)
2. 如何從ASP.NET 2.0中發(fā)送電子郵件
3. 淺談ASP.NET應用
4. ASP.NET中的ViewState本質(zhì)
5. 安裝ASP.NET AJAX的過程