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

【问题标题】：Thunderdome MVC- Why one-model-in in MVC?Thunderdome MVC - 为什么在 MVC 中使用单一模型？
【发布时间】：2010-10-05 19:44:25
【问题描述】：

当 Jeremy & Chad posted about their FubuMvc project 时，他们提到的差异化因素之一是他们的“Thunderdome 校长”：

“Thunderdome 原则”——全部控制器方法接受一个 ViewModel 对象（或零个对象某些情况下）并返回一个 ViewModel 对象（一个对象进入，一个物体离开）。控制器类永远不会直接暴露与 HttpContext 相关的任何内容。没有什么比看到更让我哭泣人们试图编写模拟测试或存根新的 IHttpContextWrapper 界面。同样，控制器方法不返回 ViewResult 对象，通常是解耦的来自所有 MVC 基础架构。我们很早就采用了这个策略一种进行控制器测试的方法机械上更简单。绝对是实现了这个目标，但它也实现了控制器代码非常精简并且易于阅读。我们将解释如何这适用于 KaizenConf。

他们的'一个 ViewModel（或零个）in' 方法的优势是什么？

【问题讨论】：

标签： asp.net-mvc controller model-view-controller viewdata fubumvc

【解决方案1】：

它的主要好处是它是一种约定，并使我们所有控制器的事情保持一致。它使我们更容易设置可以在集成测试场景中初始化环境的测试“上下文”/夹具。在大多数情况下，约定 == 快速性，因为它从您的设计考虑中消除了许多“假设”场景。

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

控制器动作有多个参数并没有错，但我们发现拥有一个实际的模型对象为我们提供了一些额外的功能，因为模型可以包含简单的逻辑并公开方便属性，这些属性可以简单地提供更多功能其自身状态的复杂方面等——基本上，这是拥有任何丰富模型的论据，并不是 Thunderdome/OMIOMO 模式独有的。

【讨论】：

好吧，我绝对可以买到它只是一个惯例的好处。我将在我即将进行的一个项目中给这个模型一个镜头。
为所有控制器设置 16 个参数也是一个惯例。约定本身不一定是好事。
@liamclennan 没错。智能约定可能是描述它的更好方式。幸运的是，没有人提倡愚蠢的约定，但感谢您指出这一点:)
@chadmyers 我没有学究气。您的第一段说 Thunderdome 很好，因为它是一种约定。我指出这不是一个有效的论点。
是的，你很迂腐。我并不是说它很好，因为它是一个约定，我说它很好，因为它是一个很好的约定。迂腐。每个人都知道你可以是传统的好或坏。这是一个好的约定，因此使用 OMIOMO 的东西也很好。

【解决方案2】：

优点是您不依赖控制器方法之外的任何类型的上下文（例如会话状态）。这使得测试它们变得更容易，因为您不必使用模拟“模拟”该上下文，但它也降低了实用性，因为您必须通过参数传递所有内容。

【讨论】：

我当然明白在测试控制器时必须模拟上下文等是一种痛苦——但我认为使用 DI 可以缓解这种痛苦。我仍然看不出让每个动作都采用一个参数有什么帮助。然后你不是将相同的测试问题转移到模型上吗？
我不认为有“一个 ViewModel（或零）”意味着你只能有一个参数。我认为你可以有两个，甚至更多。我的解释是 Action 方法不会从 Controller 类之外获取任何东西，比如 Http 上下文。我就是这么读的。
@Dave：不，Thunderdome/OMIOMO 的目的是为方法提供一个或零个输入参数，其中一个参数是丰富的模型（而不是原语），它丰富地表示操作请求
另一件事：该模型应该不是来自主域模型的实体。
有什么区别？该对象遵循与在单个对象中包含所有事件参数的 EventArgs 对象相同的模式。

【解决方案3】：

Thunderdome 原理的好处在于它简化了控制器。因为将 http 值映射到对象的工作是在控制器之外完成的，这意味着控制器只做它们应该做的事情。

【讨论】：

Modelbinder 将 http 值映射到控制器外部的操作参数，不是吗？
我真的不认为它简化了你的设计。它可能会简化控制器，但您需要在某个地方对其进行处理。
Troy 是对的，Modelbinder 会为您完成提升工作，但它们不一定能处理某些可能需要逻辑的情况。这通常由控制器负责。使用 Thunderdome/OMIOMO，它在输入模型中
@Dave Van den Eynde 我简化了设计，因为它允许控制器承担单一职责。