Недавно начал изучать паттерн MVVM и возникла дюжина вопросов. Один из них - зачем нужна ViewModel? (биндинг можно строить и в модели) Приведите, пожалуйста, примеры либо скиньте ссылки на статьи.
Ответ
Формально говоря, ViewModel - это еще один слой абстракции от реализации UI. Далее много букв.
Смысл её примерно в следующем. В стандартной парадигме MVC оставался открытым вопрос - как корректно "кодировать" логику взаимодействия с пользователем в той части, которая связана именно с пользовательскими действиями, а не с какой-то бизнес-логикой. Типичный пример - скрыть/показать группу полей при перещелкивании радио-батона, ну или, например, выполнить валидацию введенных данных при переходе на другую вкладку в рамках одного таб-контроля. Еще одним примером может быть отображение диалогового окна с запросом подтверждения действия при, например, изменении какого-то элемента.
Т.е. это действия, которые, с одной стороны, могут иметь под собой достаточно сложную логику, а с другой - вообще говоря, имеют к "модели" - цементирующей всю систему сущности, "отлитую в металле" и сохраняемую в базе - довольно отдаленное отношение. Да и с точки зрения архитектуры добавлять в модельный класс десяток булевых полей IsCheckboxSelected исключительно для сиюминутных нужд отображения - несколько некошерно.
До относительно недавнего времени мышки плакали, кололись, но продолжали есть кактус: это все размазывалось между контроллером и view, писались дополнительные классы и прослойки с репозиториями и архитектурная "красивость" решения приносилась в жертву функциональным требованиям.
Но технический прогресс, как известно, неумолим, интерфейсы стали становиться все сложнее и сложнее, асинхронность, юзабилити и все такое всякое стали доминировать. А с другой стороны еще и автоматизированное и юнит-тестирование начало триумфальное шествие по планете, и вопрос о том, как тестировать вьюхи, в которых логика взаимодействия пользователя гвоздями прибита к физическому "рендерингу" стал стоять все более и более остро.
Т.е. с одной стороны хочется иметь возможность писать (и изолированно автоматически тестировать, что тоже немаловажно) логику UI, а с другой - в ассертах очень не хочется завязываться на конкретные лейблы, тэги, контролы и т.д. и т.п.
Парадигма MVVM была разработана с целью разрешить это противоречие. В архитектуру был введен дополнительный слой - тот, что отвечает за взаимодействие с пользователем, но при этом он строится таким образом, чтобы, в идеале, было не важно отображается ли он в WPF-приложении под Windows, текстовой консоли а ля DOS или передается стуком тамтамов. Это достигается за счет того, что сами классы MVVM строятся на базе обычных POCO-объектов, логика - это методы этих же объектов, оперирующие данными в полях объектов + обработчики событий (UI все-таки по сути - штука асинхронная). А физическое отображение этих самых объектов на пользовательский интерфейс - это уже биндинги, шаблоны, конвертеры и прочие плюшки конкретной реализации - работают как производные от нашей вью-модели (т.е. привязываются к ней).
Плюсы - такие классы относительно легко (ну или хотя бы просто возможно) тестировать юнит-тестами, в целом архитектура получается более стройной, крупные приложения быстрее разрабатывать и проще поддерживать. Минусы - дополнительный оверхед на вью-модель и потребность в развитых средствах биндинга.
Как то так.
Комментариев нет:
Отправить комментарий