采访：Chad Myers 和 FubuMVC － 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 中。

InfoQ 的 Jon Arild Tørresda 询问了 Chad Myers，ASP.NET MVC 与 FubuMVC 之间最大的不同是什么：

如果非要选一个，我选择“组合对继承”。这是一个设计上的基本区别，但并不是说 ASP.NET MVC 的设计不好，只是我认为 ASP.NET MVC 在类结构设计上倾向于使用继承，因而无法像使用组合那样易于设计动态的 Web 应用程序。

FubuMVC 是一个前端控制器 （Front Controller）框架。Chad 指出这个模式的两个主要目标是：

1. 分离对请求的不同关注点
2. 允许使用组合的方式构造响应，以发回给客户端

对于前端控制器，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 ，InfoQ 问道相比于 FubuMVC 的核心框架，这个项目的目标有什么不同:

我们希望能够有更多的自由来发展 FubuMVC，因此建立了 FubuMVC Contrib。我们想尝试一下插件，这样可以有更多的人参与进来，他们可以在较少的限制下做更多的尝试，同时保持核心框架的稳定。

FubuMVC 核心框架将会维持少数几个成员，对待补丁会更谨慎，对框架的修改也会更少。FubuMVC-Contrib 将会有更多的参与者、更多的改动、更低的要求，可能有无法工作的代码或实验性质的代码。当在 contrib 中开发出有趣的东西后，可以将这些东西合并到核心框架，或者拆分到单独的项目中。

现今，FubuMVC 还没有 ASP.NET MVC 那样成熟，但是它的实现方式很有趣，这个框架将会如何发展，它与 ASP.NET MVC 的发展方向将会有怎样的不同，我们将拭目以待。关于 FubuMVC 的更多信息，可以查看他们的 wiki 和 Ryan Kelley 的从头开始学 FubuMVC 教程。

原文地址： Interview: Chad Myers on FubuMVC - An Alternative MVC Implementation in ASP.NET