Насколько независима от ViewModel в MVVM?

Question

Давайте представим очень простой интерфейс, в котором есть список флажков. При нажатии на любой из них:

1) если он не выбран, он должен создать рабочее пространство с этим именем флажка (и в этом рабочем пространстве будет доступно больше логики, но это не имеет отношения к вопросу). Флажок естественным образом становится выбранным;

2) Если он уже выбран, он должен отключиться и уничтожить соответствующее рабочее пространство.

Непосредственная форма реализации этого заключается в том, чтобы View смотрел на состояние отмеченного флажка и в зависимости от того, был ли уже выбран или не делать viewModel.createWorkpace() или viewModel.destroyWorkspace(). Но тогда это означает, что эта логика в View - у меня сложилось впечатление, что было бы лучше иметь ее в ViewModel.

Я читал, что ViewModel по разным причинам не должен знать View. Но одна вещь не имеет физической зависимости от View (ссылка на объект, например), а другая совершенно другая даже не осознает, что View может иметь флажки, как в этом примере.

У меня складывается впечатление, что на самом деле нет большого смысла в том, чтобы сильно отличать View и ViewModel, и на самом деле, чем ближе ViewModel к View, тем легче это для привязки данных между View и ViewModel.

Как мне справиться с этой ситуацией и почему?

Спасибо

Answer 1

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

Представление должно делать то, что связано с отображением данных и позволяет пользователю взаимодействовать. Модель представления должна иметь код, который воздействует на эти взаимодействия и представляет данные представлению. Это не означает, что у представления не должно быть никакого кода вообще. Однако, если есть код, он должен быть конкретным. Хорошей идеей является использование повторно используемого кода, например поведения. Потому что тогда вы можете вручную проверить их и доказать, что они работают. Затем повторно используйте проверенный код. Аналогично с преобразователями, валидаторами и т. Д.

Весь код.

Все используемые в представлениях.

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

Менее важно, чтобы представление ничего не знало о модели представления, чем наоборот. Вы не собираетесь создавать экземпляр для выполнения тестов, если только для него не создан экземпляр модели представления. Это не значит, что вы должны просто вставить весь свой код в код позади.

Почему это именно так? Потому что бог MVVM ударит тебя своими молниями? Нету. Потому что это облегчит будущее развитие? Ну, может, но обычно не так много, как вы могли бы заметить.

Почему тогда? Потому что создание экземпляра представления с его элементами управления очень медленное. У них неизбежно много зависимостей, над которыми вы не можете издеваться. Скорее всего, это зависит от ресурса в приложении, поэтому вам нужно создать экземпляр приложения и объединить словари ресурсов. Представления часто зависят от наборов библиотек, изображений, пользовательских контролей и т. Д. И т. Д. Ни один из которых вы не можете издеваться. Так что тебе нужно все. К тому времени, когда вы автоматизируете создание всех экземпляров в каком-либо тестовом средстве и сгладьте все, нажимая на кнопки и т.д ... Ваша голова будет болеть, и вы обнаружите, что те тесты 2000 года, которые теоретически вы хотите выполнить через пару секунд каждые 10 минут, занимают гораздо больше времени, чем эта пара секунд. Вы не можете сделать «правильный» TDD, если создаете экземпляры представлений в тестах.

Чтобы ответить на ваш вопрос о флажке рабочей области. Это зависит от того, что на самом деле является рабочим пространством.

Распространенным шаблоном будет инициирование кода в установщике свойства viewmodel, связанного со свойством ischecked каждого флажка. Это может быть в представленной модели для каждого флажка, в которой указано имя рабочей области, ее тип или все, что требуется для ее проверки. Каждый из них будет содержать какую-то ссылку на эти вещи, которые он создает, так что он может распоряжаться ими или чем угодно, когда это проверенное значение становится ложным.