ASP.NET上的另一个MVC实现

　在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 (）建议我将之称为“行为”，因为这个词语准确描述了所发生的事，我有点喜欢这个名字。

　　在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教程。