如何理解ASP.NETMVC实现的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问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注创新互联行业资讯频道了解更多相关知识。