ViewModel тоже порой понимают довольно превратно, поэтому для прозрачности, давайте понимать под ней, то что понимали в первоисточнике The MVVM pattern Там ViewModel используется для отделения View от Model'и и выступает в роли адаптера ViewModel адаптирует API модели для потребителя в лице View
Теперь рассмотрим ваши кейсы
1) Приходят задачи по UI - меняется UI и ViewModel Если под задачей UI мы понимаем "поменять цвет текста" или "подвинуть кнопку", то ViewModel не меняется Но если надо отобразить новые данные, например, "кроме цены товара показать скидку", то это задача не только для UI, но и для адаптера. То есть ViewModel придётся менять. Новые данные, если они есть в Model, как минимум надо подготовить для View.
Но их там может не быть. Тогда нам нужно сначала добавить знание о скидках в Domain Model, а это самый верхний слой, который может повлиять на все остальные И тут мы подходим к двум другим кейсам
2) задачи по сервисам - меняется соответствующий сервис и ViewModel, задачи по бд - меняется бд и опять же ViewModel
Просто добавить новое свойство в доменную модель недостаточно, ведь нам нужно откуда-то взять данные для него, и точно не из View) В нашем примере новые данные будут браться из репозитория, за которым будет поход в сеть или в базу данных. Таким образом в контракт между репозиторием и слоем бизнес-логики надо внести дополнение, так как теперь модель товара должна содержать ещё и информацию о скидке. Адаптер, коим выступает репозиторий, конечно, изменится.
Однако, если изменения не затрагивают верхние слои, скажем, если мы меняем тип базы данных или способ хранения (запилили парочку нормализаций), то ничего кроме самой БД и относящихся к ней адаптеров не поменяется. Доменная сущность будет той же самой, бизнес-логика не изменится, классическая ViewModel тем более.
Предположу, что в вашем примере логика Model'и смешалась с ViewModel, а возможно последняя выступает адаптером не только для View, но и сразу для всех (сеть, база данных и тд). Такой подход встречается часто, так как прост и избавляет от дополнительных сущностей. Но не очень чист. Минус в том, что ViewModel берёт на себя много ответственностей и разрастается, превращаясь в god object. Для маленьких классов не фатально, для больших критично.
Спасибо за развёрнутый комментарий Уверен, он станет ценным дополнением для читателей статьи
Смею заверить, что статью не генерировала никакая искусственная нейросетка. Исключительно естественная GAN система путём проб и ошибок)
Значительна часть подверглась корректировке и упрощению, чтобы материал легче читался и был доступнее для целевой аудитории - разработчиков начального и среднего уровня. Действительно, местами пришлось пожертвовать научной точностью, ради педогагической ценности. Так же, как в школьной физике говорят про электрон вращающийся вокруг ядра, но для физика-атомщика это неприемлимое описание электронных орбиталей
В статье приводится взгляд со стороны рядового разработчика для такого же рядового разработчика, не профи архитектора (им такой материал навряд ли интересен) Боюсь, если с порога начать про несколько видов архитекторов и того, за что каждый из них отвечает, то объём новой информации может попросту перегрузить неподготовленного читателя, чего, конечно же, не хотелось бы) Так же с различием архитектуры и дизайна. Ощущение границы приходит с опытом проектирования. Начинающему разработчику объяснить её было бы сложно, а опытному уже не нужно) Но если можете привести простой пример буду благодарен
Надеюсь, что те из читателей, кто захочет погрузиться в увлекательный мир Software architecture design не удовлетворятся одной лишь статьей на хабре или википедией и обратятся к фундаментальным трудам и первоисточникам.
Да, было бы интересно взглянуть
Спасибо за вопрос
Давайте разбираться)
ViewModel тоже порой понимают довольно превратно, поэтому для прозрачности, давайте понимать под ней, то что понимали в первоисточнике The MVVM pattern
Там ViewModel используется для отделения View от Model'и и выступает в роли адаптера ViewModel адаптирует API модели для потребителя в лице View
Теперь рассмотрим ваши кейсы
1) Приходят задачи по UI - меняется UI и ViewModel
Если под задачей UI мы понимаем "поменять цвет текста" или "подвинуть кнопку", то ViewModel не меняется
Но если надо отобразить новые данные, например, "кроме цены товара показать скидку", то это задача не только для UI, но и для адаптера. То есть ViewModel придётся менять. Новые данные, если они есть в Model, как минимум надо подготовить для View.
Но их там может не быть. Тогда нам нужно сначала добавить знание о скидках в Domain Model, а это самый верхний слой, который может повлиять на все остальные
И тут мы подходим к двум другим кейсам
2) задачи по сервисам - меняется соответствующий сервис и ViewModel, задачи по бд - меняется бд и опять же ViewModel
Просто добавить новое свойство в доменную модель недостаточно, ведь нам нужно откуда-то взять данные для него, и точно не из View)
В нашем примере новые данные будут браться из репозитория, за которым будет поход в сеть или в базу данных. Таким образом в контракт между репозиторием и слоем бизнес-логики надо внести дополнение, так как теперь модель товара должна содержать ещё и информацию о скидке. Адаптер, коим выступает репозиторий, конечно, изменится.
Однако, если изменения не затрагивают верхние слои, скажем, если мы меняем тип базы данных или способ хранения (запилили парочку нормализаций), то ничего кроме самой БД и относящихся к ней адаптеров не поменяется. Доменная сущность будет той же самой, бизнес-логика не изменится, классическая ViewModel тем более.
Предположу, что в вашем примере логика Model'и смешалась с ViewModel, а возможно последняя выступает адаптером не только для View, но и сразу для всех (сеть, база данных и тд).
Такой подход встречается часто, так как прост и избавляет от дополнительных сущностей. Но не очень чист. Минус в том, что ViewModel берёт на себя много ответственностей и разрастается, превращаясь в god object. Для маленьких классов не фатально, для больших критично.
Спасибо за развёрнутый комментарий
Уверен, он станет ценным дополнением для читателей статьи
Смею заверить, что статью не генерировала никакая искусственная нейросетка. Исключительно естественная GAN система путём проб и ошибок)
Значительна часть подверглась корректировке и упрощению, чтобы материал легче читался и был доступнее для целевой аудитории - разработчиков начального и среднего уровня. Действительно, местами пришлось пожертвовать научной точностью, ради педогагической ценности. Так же, как в школьной физике говорят про электрон вращающийся вокруг ядра, но для физика-атомщика это неприемлимое описание электронных орбиталей
В статье приводится взгляд со стороны рядового разработчика для такого же рядового разработчика, не профи архитектора (им такой материал навряд ли интересен)
Боюсь, если с порога начать про несколько видов архитекторов и того, за что каждый из них отвечает, то объём новой информации может попросту перегрузить неподготовленного читателя, чего, конечно же, не хотелось бы)
Так же с различием архитектуры и дизайна. Ощущение границы приходит с опытом проектирования. Начинающему разработчику объяснить её было бы сложно, а опытному уже не нужно) Но если можете привести простой пример буду благодарен
Надеюсь, что те из читателей, кто захочет погрузиться в увлекательный мир Software architecture design не удовлетворятся одной лишь статьей на хабре или википедией и обратятся к фундаментальным трудам и первоисточникам.