When ASP.NET MVC was first made available, Jeremy D. Miller and Chad Myers worked with the pre release versions and changed some of the underlying implementation. Later almost nothing was left of the original ASP.NET MVC implementation and they decided to create the alternative ASP.NET MVC implementation FubuMVC. Later they invited in Mark Nijhof as one of the major contributors to the project.
Fubu is short for “For us, by us”. Today FubuMVC does not use any of ASP.NET MVC, except from ASP.NET Routing, which is now part of the .NET Framework 3.5 SP1.
Jon Arild Tørresdal from InfoQ sat down with Chad Myers and asked what the major difference between ASP.NET MVC and FubuMVC are:
If I had to pick one, I would say “a philosophy of composition vs. inheritance.” It’s a fundamental difference in design. That is not to say that ASP.NET MVC is bad design - quite the contrary. It’s just that I don’t think ASP.NET MVC’s tend towards inheritance in various class design structures lends itself as well towards a dynamic web application design as does the compositional approach.
FubuMVC is a Front Controller style framework. Chad points out two primary goals of this pattern:
- Separate various disparate concerns of servicing the request
- Allow for the composition of the response to be sent back to the client
In relation to the Front Controller Chad comments “we found that it was difficult, but not impossible to implement proper Front Controller using ASP.NET MVC.”
One of the implementation decisions made in the FubuMVC framework is the concept of “behavior” before and after a controller action. Chad explains the history behind why they decided to call it behavior and what it means in FubuMVC:
When showing a very early, rough-cut of FubuMVC to a group of folks during a Virtual ALT.NET (VAN) meeting, Steven Harman (http://stevenharman.net) suggested I call them “Behaviors” as it more accurately describes what’s going on. The name has stuck and I actually kind of like it.
Behaviors in FubuMVC are really an implementation of a hybrid between the Decorator and Chain of Responsibility design patterns.
...
Behaviors have full control over the request pipeline and can usurp the processing entirely, can add/modify incoming requests, can dynamically choose which action to execute or even whether to execute an action at all, can modify the output from an action or replace it entirely, and can execute code after the request is finished. In fact, rendering the view to the browser is actually a behavior. FubuMVC uses behaviors itself to achieve baseline functionality. This functionality and these behaviors can be replaced or modified to suit your needs.
Mark Nijhof illustrates this pipeline in his article about FubuMVC and the Front Controller style framework:
According to Chad, “behaviors have opened up new possibilities that aren’t easily achievable in other frameworks”:
- The ability to wrap the entire request in a try/catch/finally block
- The ability to cache at multiple levels
- The ability to dynamically invoke actions based on various runtime or request-time circumstances
Another aspect a MVC pattern implementation gives developers is the ability to unit test code that traditionally was un-testable UI code. Chad comments on how Microsoft has implemented this:
...the Microsoft team has made great strides in the recent updates to the MVC framework (the Beta, the RC, and now the Release) and it is considerably better than in the Preview 3 days, I still feel that the over-use of inheritance, excessive defensive coding, and the intentional decision not to use interfaces has made testing with ASP.NET MVC cumbersome.
He continues by explaining how FubuMVC have implemented the pattern:
FubuMVC, on the other hand, uses small, properly-segregated interfaces that are easily mock-able. The framework focuses on loose coupling and high cohesion. At this point, I’d say it succeeds more in the former than the later, though. It’s still a work in progress and I hope to develop the design to be more cohesive.
FubuMVC relies heavily upon the SOLID principles which enable greater flexibility for developers to stub out and even replace entire sections of the framework with a single mock using their favorite mocking framework.
FubuMVC intentionally does not have many defensive coding checks.
…instead, most of the focus of freedom-of-design is in the parts where the majority of client code will occur: controllers, behaviors, views, and override-able portions of the framework – in that order.FubuMVC classes generally have few dependencies and those dependencies are to interface abstractions which are easily mock-able.
Having Jeremy involved in the project (creator of the IoC container StructureMap) one would think that great attention has been given to Inversion of Control and support for IoC containers, and of course it has:
Currently it “ships” with support for StructureMap, but it is likely support will be added for other containers in the future. The use of the container is kept on the edge and is only referenced during configuration-time. Everything else flows naturally out of the container using the container’s auto-wiring features so there is hardly any usage of “service location.” What little service location there is is done through the Microsoft Patterns and Practices Common Service Locator framework which allows the easy plugging of other underlying IoC containers that adhere to the CSL pattern (which most do).
FubuMVC also has a contrib project and InfoQ asked where this project is heading compared to the core of FubuMVC:
FubuMVC Contrib was created because we wanted to have some more freedom to play with various usages of FubuMVC. We wanted to experiment with add-ons, allow more contributors and more contributions, and generally to be able to experiment more with a slightly lower degree of discipline and rigor reserved for the core framework.
FubuMVC core will have fewer contributors, patches will be treated much more seriously, and will change less often. FubuMVC-Contrib will have more contributors, more changes, higher tolerance for change, and may have broken or experimental code. As interesting things develop in contrib, they may get rolled up into core or spin off onto their own projects.
Today the FubuMVC project is not as mature as ASP.NET MVC, but the implementation differences are interesting. It will also be interesting to see how this framework will evolve and in which direction compared to ASP.NET MVC. To find out more about FubuMVC, check out their wiki and also Ryan Kelley’s FubuMVC from scratch articles.