Thunderdome MVC-为什么在MVC中的一个模型？ [英] Thunderdome MVC- Why one-model-in in MVC?

问题描述

当Jeremy& Chad 关于他们的FubuMvc项目，他们提到的区别之一是他们的Thunderdome校长：

When Jeremy & Chad posted about their FubuMvc project, one of the differentiators they mentioned was their "Thunderdome Principal":

Thunderdome Principle - 所有
控制器方法接收一个
ViewModel对象（或在
中的零对象）并返回一个
ViewModel对象对象进入，
一个对象离开）。控制器
类将不会直接暴露
到与HttpContext相关的任何东西。
没有什么让我哭泣像看到
人试图编写测试，模拟
或存根新的IHttpContextWrapper
接口。同样，Controller
方法不返回ViewResult
对象，通常是从所有MVC基础结构中解耦
。我们
很早就采用了这个策略，因为
是一种使控制器测试
机械更简单的方法。它肯定是
实现了这个目标，但它也使
控制器代码非常流线型
和易于阅读。我们将在KaizenConf中解释
是如何工作的。

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.

它们的一个ViewModel或者零）在方法中？

What is the advantage of their 'one ViewModel (or zero) in' approach?

推荐答案

它的主要好处是它是一个约定，我们的控制器。它使我们更容易设置测试上下文/ fixtures，可以在集成测试场景中初始化环境。在大多数情况下，惯例==快速，因为它从你的设计考虑中删除了很多假设情景。

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.

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

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.

这篇关于Thunderdome MVC-为什么在MVC中的一个模型？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！