当 Jeremy & Chad发布他们的 FubuMvc 项目时，他们提到的差异化因素之一是他们的“Thunderdome Principal”：
“Thunderdome 原则”——所有 Controller 方法都接受一个 ViewModel 对象（或在某些情况下为零个对象）并返回一个 ViewModel 对象（一个对象进入，一个对象离开）。Controller 类永远不会直接暴露给与 HttpContext 相关的任何内容。没有什么比看到人们尝试编写模拟或存根新 IHttpContextWrapper 接口的测试更让我哭泣的了。同样，Controller 方法不返回 ViewResult 对象，并且通常与所有 MVC 基础结构分离。我们很早就采用了这种策略，以使控制器测试在机械上更简单。它确实实现了这个目标，但它也使 Controller 代码非常精简且易于阅读。我们将在 KaizenConf 解释这是如何工作的。
他们的“一个 ViewModel（或零）”方法的优势是什么？
它的主要好处是它是一种约定，并使我们所有控制器的事情保持一致。它使我们更容易设置可以在集成测试场景中初始化环境的测试“上下文”/夹具。在大多数情况下，Conventions == Rapidity，因为它从您的设计考虑中消除了许多“假设”场景。
由于我们所有的控制器操作都遵循相同的模式，我们可以假设很多事情，它可以加速和简化我们的控制器集成测试工作。
控制器动作有多个参数当然没有错，但是我们发现拥有一个实际的模型对象为我们提供了一些额外的功能，因为模型可以包含简单的逻辑并公开便利属性，这些属性可以简单地处理一些更复杂的方面它自己的状态等——基本上，这是拥有任何丰富模型的论据，并不是 Thunderdome/OMIOMO 模式所独有的。
优点是您不依赖控制器方法外部的任何类型的上下文（例如会话状态）。这使得测试它们变得更容易，因为您不必使用模拟“模拟”该上下文，但它也使其不太实用，因为您必须通过参数传递所有内容。
Thunderdome 原理的好处是它简化了控制器。因为将 http 值映射到对象的工作是在控制器之外完成的，这意味着控制器只做它们应该做的事情。