Thunderdome MVC - 为什么在 MVC 中使用一个模型？
当杰里米和 查德 发布了他们的 FubuMvc 项目，他们提到的与众不同之处之一是他们的“Thunderdome Primary”：
“雷霆穹顶原则”——全部 控制器方法合二为一 ViewModel 对象（或中的零对象） 某些情况下）并返回一个 ViewModel对象（一个对象进入， 一个物体离开）。 控制器 类永远不会直接暴露 与 HttpContext 相关的任何内容。 没有什么比看到更让我哭泣 人们试图编写模拟测试 或存根新的 IHttpContextWrapper 界面。 同样，控制器 方法不返回 ViewResult 对象并且通常是解耦的 来自所有 MVC 基础设施。 我们 很早就采用了这一策略 一种进行控制器测试的方法 机械上更简单。 绝对是 实现了这个目标，但也取得了 控制器代码非常精简 并且易于阅读。 我们将解释如何 这在 KaizenConf 上有效。
他们的“一个 ViewModel（或零个）”方法的优点是什么？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
它的主要好处是它是一种约定，并使我们所有控制器之间的事情保持一致。 它使我们更容易设置可以在集成测试场景中初始化环境的测试“上下文”/装置。 在大多数情况下，约定==快速，因为它从您的设计考虑中消除了许多“假设”场景。
由于我们所有的控制器操作都遵循相同的模式，因此我们可以假设很多事情，它加速并简化了我们的控制器集成测试工作。
控制器操作有多个参数必然没有什么问题，但我们发现拥有一个实际的模型对象为我们提供了一些额外的功能，因为模型可以包含简单的逻辑并公开便利的属性，这些属性可以简单地处理一些更复杂的方面它自己的状态等等——基本上，这是拥有任何丰富模型的论点，并且不是 Thunderdome/OMIOMO 模式所独有的。
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.
优点是您不依赖于控制器方法外部的任何类型的上下文（例如会话状态）。 这使得测试它们变得更容易，因为您不必使用模拟“模拟”该上下文，但它也使其不太实用，因为您必须通过参数传递所有内容。
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.
雷顶原理的好处是它简化了控制器。 因为将 http 值映射到对象的工作是在控制器外部完成的，这意味着控制器只做它们应该做的事情。
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.