Зачем нужна ViewModel в шаблоне MVVM, С#?

#c_sharp #mvvm

Недавно начал изучать паттерн MVVM и возникла дюжина вопросов.
Один из них - зачем нужна ViewModel? (биндинг можно строить и в модели)
Приведите, пожалуйста, примеры либо скиньте ссылки на статьи.
    

Ответы

Ответ 1

Формально говоря, ViewModel - это еще один слой абстракции от реализации UI. Далее
много букв. 

Смысл её примерно в следующем. В стандартной парадигме MVC оставался открытым вопрос
- как корректно "кодировать" логику взаимодействия с пользователем в той части, которая
связана именно с пользовательскими действиями, а не с какой-то бизнес-логикой. Типичный
пример - скрыть/показать группу полей при перещелкивании радио-батона, ну или, например,
выполнить валидацию введенных данных при переходе на другую вкладку в рамках одного
таб-контроля. Еще одним примером может быть отображение диалогового окна с запросом
подтверждения действия при, например, изменении какого-то элемента.

Т.е. это действия, которые, с одной стороны, могут иметь под собой достаточно сложную
логику, а с другой - вообще говоря, имеют к "модели" - цементирующей всю систему сущности,
"отлитую в металле" и сохраняемую в базе - довольно отдаленное отношение. Да и с точки
зрения архитектуры добавлять в модельный класс десяток булевых полей IsCheckboxSelected
исключительно для сиюминутных нужд отображения - несколько некошерно. 

До относительно недавнего времени мышки плакали, кололись, но продолжали есть кактус:
это все размазывалось между контроллером и view, писались дополнительные классы и прослойки
с репозиториями и архитектурная "красивость" решения приносилась в жертву функциональным
требованиям. 

Но технический прогресс, как известно, неумолим, интерфейсы стали становиться все
сложнее и сложнее, асинхронность, юзабилити и все такое всякое стали доминировать.
А с другой стороны еще и автоматизированное и юнит-тестирование начало триумфальное
шествие по планете, и вопрос о том, как тестировать вьюхи, в которых логика взаимодействия
пользователя гвоздями прибита к физическому "рендерингу" стал стоять все более и более
остро.

Т.е. с одной стороны хочется иметь возможность писать (и изолированно автоматически
тестировать, что тоже немаловажно) логику UI, а с другой - в ассертах очень не хочется
завязываться на конкретные лейблы, тэги, контролы и т.д. и т.п.

Парадигма MVVM была разработана с целью разрешить это противоречие. В архитектуру
был введен дополнительный слой - тот, что отвечает за взаимодействие с пользователем,
но при этом он строится таким образом, чтобы, в идеале, было не важно отображается
ли он в WPF-приложении под Windows, текстовой консоли а ля DOS или передается стуком
тамтамов. Это достигается за счет того, что сами классы MVVM строятся на базе обычных
POCO-объектов, логика - это методы этих же объектов, оперирующие данными в полях объектов
+ обработчики событий (UI все-таки по сути - штука асинхронная). А физическое отображение
этих самых объектов на пользовательский интерфейс - это уже биндинги, шаблоны, конвертеры
и прочие плюшки конкретной реализации - работают как производные от нашей вью-модели
(т.е. привязываются к ней).

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

Как то так.