Thunderdome MVC - почему одна модель в MVC?

Question

Когда Джереми и Чад опубликовали информацию о своем проекте FubuMvc , одним из отличий, которые они упомянули, был их "Принцип Громовержи":

«Принцип грома» - все Методы контроллера берут в одном Объект ViewModel (или ноль объектов в некоторые случаи) и вернуть один ViewModel объект (один объект входит, один объект уходит). Контроллер классы никогда не будут выставлены ко всему, что связано с HttpContext. Ничто так не заставляет меня плакать люди пытаются писать тесты, которые издеваются или заглушка, что новый IHttpContextWrapper интерфейс. Аналогично, Контроллер методы не возвращают ViewResult объекты и, как правило, отделены из всей инфраструктуры MVC. Мы принял эту стратегию очень рано, как способ сделать тестирование контроллера проще механически. Это определенно достигла этой цели, но она также Код контроллера очень упрощен и легко читается. Мы объясним, как это работает на KaizenConf.

В чем преимущество их 'одной ViewModel (или нуля) в подходе * ?

Answer 1

Его основное преимущество заключается в том, что это соглашение и обеспечивает согласованность всех наших контроллеров. Это облегчает нам настройку «контекстов» / приспособлений тестирования, которые могут инициализировать среду в сценарии интеграционного тестирования. В большинстве случаев условные обозначения == быстрота, поскольку это устраняет множество сценариев "что, если" из ваших соображений проектирования.

Поскольку все наши действия контроллера выполняются по одной схеме, мы можем предполагать много вещей, и это ускоряет и оптимизирует наши усилия по интегрированному тестированию контроллера.

В этом нет ничего плохого, обязательно наличие нескольких аргументов для действия контроллера, но мы обнаружили, что наличие фактического объекта модели дает нам некоторые дополнительные функциональные возможности, поскольку модель может содержать простую логику и предоставлять удобные свойства, которые могут просто некоторые из сложные аспекты его собственного состояния и т. д. - в основном, это аргумент в пользу наличия какой-либо богатой модели и не уникален для паттерна Thunderdome / OMIOMO.

Answer 2

Преимущество принципа грома состоит в том, что он упрощает контроллеры. Поскольку работа по отображению значений http на объекты выполняется вне контроллеров, это означает, что контроллеры выполняют только то, что должны.

Answer 3

Преимущество заключается в том, что вы не полагаетесь на какой-либо контекст (например, состояние сеанса) извне методов контроллера. Это облегчает их тестирование, поскольку вам не нужно «имитировать» этот контекст с помощью имитаций, но это также делает его менее практичным, поскольку вы должны передавать все по параметрам.