FubuMVC - Front Controller style framework

FubuMVC is a sort of Front Controller style framework and what this means is that the C in MVC is not just the WhateverController class, but the C is actually a series of classes chained together. The main reason behind this is because proper “Separation of Concern” does not allow the WhateverController class to have different responsibilities, so to separate the different responsibilities the C actually is a combination of an ActionInvoker, a chain of Behaviors and the ControllerAction.

To illustrate how this works I would like to show you how a request flows through the FubuMVC framework. It all starts at IIS receiving the request, then the first step is that the request is passed to the ASP.Net Routing library which is part of the System.Web.Routing namespace (not the System.Web.MVC namespace) which handles the URL routing for FubuMVC. Once the routing library gets an URL that was configured by FubuMVC (through convention and alternately overridden by configuration) it will ask for the proper HttpHandler to handle this request which is the FubuMVC ActionHttpHandler. This HttpHandler will then execute the Invoke method on the ThunderdomeActionInvoker.

The first thing the ThunderdomeActionInvoker will do is create the specified input view model for the controller and use reflection to populate it with the possible values that where passed along with the request in the form of GET and POST variables. This means that GET and POST variables can only be accessed via the type save input view model.

After setting up the input view model the ThunderdomeActionInvoker will call the invoke method on the first assigned behavior for the current ControllerAction. Now behaviors are a very powerful thing in FubuMVC because they will let you modify the view model that eventually gets send to the view either before it arrives at the ControllerAction or after it is processed by the ControllerAction. Behaviors are chained together and they can vary depending on the ControllerAction.

A behavior should have only one concern, this blog for example uses NHibernate and NHibernate works with Sessions. One behavior "access_the_database_through_a_unit_of_work" makes sure that each request is encapsulated with a single session and at the end of the request the transaction will be committed. Another behavior "OutputAsRssOrAtomFeed" that I use is one that looks at the request and depending on the existence of the “.rss” extension it will render the view model to proper RSS XML.

Then after all the behaviors have had their PrepareInput triggered the ControllerAction (commonly known as the Controller) will be triggered. Each Controller has by convention an Index(ViewModel) method which is the default ControllerAction, but it can others as well, for example when posting a form back to the same controller you would have a different ControllerAction deal with saving the data and after that redirect the result again to the default ControllerAction.

Now comes a little treat, after the ControllerAction was called all the behaviors will get their ModifyOutput method called and this happens in the reversed order as the PrepareInput method was called, this in effect making it possible to encapsulate a request without having to use an extra HttpHandler.

You will need at least one behavior to render the view using the view model towards the client. FubuMVC has a build in behavior for this called “execute_the_result”.

As you can see the way that FubuMVC uses behaviors is an ideal way to separate your different concerns, and it makes your controllers open for extension and closed for modification (well it helps, you still have to adhere to the Dependency Inversion Principle in the controller). Another thing is that the FubuMVC framework is completely wired by an IoC container, my site is using StructureMap, but since it uses the Common Service Locator you are free to use whatever container you which.