Существуют ли веские причины для представления логики (методов) в классах модели

Question

Сегодня я делал обзор кода и увидел, что у кого-то есть классы моделей представления, которые помимо данных содержат разные методы, например

GetTable, GetPdf, LoadSomeData etc.

Лично мне это не понравилось, так как я предпочел"простой" вид Классовые модели, содержащие только свойства и помещающие логику либо в контроллер, либо в дополнительную службу.

Но при рассмотрении мне не удалось найти хороших аргументов для этого.Подумайте, является ли это хорошим способом (стилем) иметь логику в представлении классов моделей?Какие плюсы / минусы?

РЕДАКТИРОВАТЬ: Это было приложение ASP.net MVC2.РЕДАКТИРОВАТЬ: Пример (только из головы) такого кода ..

public ActionResult SomeAction()
{
   var model = new ViewModel();
   model.LoadSomethingFromSomething();
   model.AnotherMethod();

   return View(model);
}

Answer 1

Принцип разделения интересов и принципал единой ответственности диктует, что единственной "логикой", которая должна содержаться в представлении, должна быть та, которая управляет отображением представления данные. Все остальное должно быть в контроллере. Семантически представление делает одну вещь - отображает данные, все, что не связано с отображением указанных данных - то есть манипулирование данными, форматирование данных, загрузка данных, преобразование данных и т. Д. Должно обрабатываться контроллером.

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

Если GetTable относится к загрузке конструкции таблицы (то есть таблицы HTML) для представления, то, возможно, это уместно, если мы говорим о получении данных таблицы из базы данных, то это не так.

Answer 2

Раньше я подписывался на идею совершенно «глупых» моделей ... т.е. тех, которые ничего не делают. Однако после использования этой идеи на практике я обнаружил, что она не идеальна. Теперь я согласен с идеей, что viewModels должен знать о том, как создавать себя из других объектов.

И.Е.

public ActionResult SomeAction(int? id)
{
   var serviceModel = _myService.Get(id ?? 0);
   var model = new ViewModel(serviceModel);

   return View(model);
}

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

Затем, чтобы вывести объект из viewModel, вы можете сделать следующее:

[HttpPost]
public ActionResult SomeAction(ViewModel model)
{
   _myService.Update(model.MapToServiceModel() );

   return SomeAction(model.id);
}

Answer 3

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

ИМО, контроллеры тоже должны быть тонкими и легкими. Мне нравится, что большая часть моей логики находится в моих моделях, а также на уровне доступа к данным. Просто в зависимости от того, о какой логике мы говорим.