Thunderdome MVC-为什么在MVC中使用单模型？

当Jeremy&Chad 发布他们的FubuMvc项目时,他们提到的一个区别是他们的"Thunderdome Principal":

"Thunderdome Principle" - 所有Controller方法都接受一个ViewModel对象(在某些情况下为零对象)并返回一个ViewModel对象(一个对象进入,一个对象离开).Controller类永远不会直接暴露给与HttpContext相关的任何东西.没有什么能让我哭泣,就像看到人们试图编写模拟或存根新IHttpContextWrapper接口的测试一样.同样,Controller方法不返回ViewResult对象,并且通常与所有MVC基础结构分离.我们很早就采用了这种策略,以便使控制器测试更加简单.它绝对实现了这一目标,但它也使得Controller代码非常简化并且易于阅读.我们将在KaizenConf解释它是如何工作的.

他们的'一个ViewModel(或零)'方法有什么优势？

它的主要好处是它是一种惯例,并使我们所有控制器的内容保持一致.它使我们更容易设置可在集成测试场景中初始化环境的测试"上下文"/夹具.在大多数情况下,约定==快速,因为它从您的设计考虑中删除了很多"假设"场景.

由于我们所有的控制器操作都遵循相同的模式,因此我们可以假设很多事情并加速并简化我们的控制器集成测试工作.

有一个控制器动作有多个参数,没有什么不对,但是我们发现有一个实际的模型对象为我们提供了一些额外的功能,因为模型可以包含简单的逻辑并暴露方便属性,这可能只是一些更复杂的方面.它自己的状态等 - 基本上,这是拥有任何丰富模型的论据,并不是Thunderdome/OMIOMO模式所独有的.