title: Thunderdome MVC- Why one-model-in in MVC?
body: <p>When Jeremy &amp; Chad <a href="http://codebetter.com/blogs/jeremy.miller/archive/2008/10/23/our-opinions-on-the-asp-net-mvc-introducing-the-thunderdome-principle.aspx" rel="noreferrer">posted about their FubuMvc project</a>, one of the differentiators they mentioned was their "Thunderdome Principal":</p>
  
  <blockquote>
    <p>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.</p>
  </blockquote>
  
  <p>What is the advantage of their <em>'one ViewModel (or zero) in'</em> approach?</p>