ViewModels могут быть очень полезны в MVP, и я считаю, что они дают больше преимуществ, чем затраты на дополнительное кодирование.
Я думаю, что руководящим правилом является использование их там, где они вам нужны, а не просто добавление большего количества шаблонов или архитектуры ради них самих.
Я работаю над публичным веб-приложением asp.net достойного размера, но следующее относится и к MVP в WinForms. Ниже приведены причины, по которым я нашел использование VM в MVP.
Сайт собирает данные из множества веб-сервисов LOB. Услуги поддерживаются различными группами разработчиков в разных бизнес-вертикалях. Данные возвращаются повсюду с точки зрения:
- Тип Soup - Хранение идентификаторов GUID в виде строк, возврат двойных символов вместо десятичных, даты в виде строк и т. Д.
- Сумасшедшие соглашения об именах - свойства падежа верблюда, подчеркивание в именах, аббревиатура, перемешивание
Но самая большая причина, по которой я нашел это, была в том, что предоставленная модель была такой же, как в MVC: модели просто не соответствовали форме представлений. Мы объединяем классы моделей и добавляем дополнительные поля для вычислений или агрегированных значений и т. Д.
С точки зрения изменений, которые мы сделали, мы должны были:
- Создайте новую папку ViewModels рядом с папкой Views и Presenters (Controllers)
- Сопоставить значения модели с моделью вида
- Измените свойство в интерфейсе вида с типа модели на тип модели вида
- Реализация представления в соответствии с новым объектом
Единственная часть, отнимающая много времени, это, естественно, отображение моделей в модель представления. В нашем случае мы вынуждены выполнить приличную часть обработки в наших докладчиках, чтобы получить данные, которые нам нужны, чтобы назначение свойств не имело большого значения. Для более простых нужд что-то вроде AutoMapper устранит эту боль для отображений.