Thunderdome MVC- Why one-model-in in MVC?

Question

When Jeremy & Chad posted about their FubuMvc project, one of the differentiators they mentioned was their "Thunderdome Principal":

The “Thunderdome Principle” – All Controller methods take in one ViewModel object (or zero objects in some cases) and return a single ViewModel object (one object enters, one object leaves). The Controller classes will NEVER be directly exposed to anything related to HttpContext. Nothing makes me cry like seeing people trying to write tests that mock or stub that new IHttpContextWrapper interface. Likewise, Controller methods do not return ViewResult objects and are generally decoupled from all MVC infrastructure. We adopted this strategy very early on as a way to make Controller testing simpler mechanically. It’s definitely achieved that goal, but it’s also made the Controller code very streamlined and easy to read. We’ll explain how this works at KaizenConf.

What is the advantage of their 'one ViewModel (or zero) in' approach?

Answer 1

The advantage is that you don't rely on any sort of context (like session state, for example) from outside the controller methods. That makes it easier to test them, as you don't have to "simulate" that context using mocks, but it also makes it less practical as you have to pass everything by parameters.

Answer 2

The benefit of the thunderdome principle is that it simplifies the controllers. Because the work of mapping http values to objects is done outside of the controllers it means that the controllers only do what they should.

Answer 3

Its primary benefit is that it's a convention and makes things consistent across all our controllers. It makes it easier for us to set up testing "contexts"/fixtures that can initialize the environment in an integration testing scenario. In most cases, Conventions == Rapidity as it removes a lot of "what if" scenarios from your design considerations.

Since all our controller actions follow the same pattern, we can assume many things and it accelerates and streamlines our controller integrated testing efforts.

There's nothing wrong, necessarily, with having multiple arguments to a controller action, but we found that having an actual model object affords us some extra functionality since the model can contain simple logic and expose convenience properties which can simply some of the more complex aspects of its own state, etc -- basically, this is the argument for having any rich model and isn't unique to the Thunderdome/OMIOMO pattern.