Какова реальная цель ViewModel в MVVM?

Question

Я пообщался с командой по этой теме, и с его точки зрения мы можем просто использовать привязки и команды, исключающие ViewModel, потому что мы можем тестировать поведение пользовательского интерфейса без VM с помощью Automation или наших собственных разработанных механизмов тестирования пользовательского интерфейса (на основе автоматических кликов на представлениях). Итак, если нет реальных преимуществ, почему я должен создавать «избыточные» объекты? Кроме того, автоматические интеграционные тесты выглядят гораздо более показательными, чем тесты VM. Таким образом, кажется, что мы можем смешивать виртуальные машины и модели.

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

Итак, какие плюсы для ВМ вы знаете?

Answer 1

VM - это логика вашего пользовательского интерфейса. объединение кода пользовательского интерфейса с логикой заканчивается беспорядком, по крайней мере, из моего опыта. Ваше представление должно определять, что вы видите - кнопки, меню и т. Д. Ваша виртуальная машина отвечает за события привязки и обработки, вызванные пользователем.

Edit:
Не желая создать виртуальную машину для каждого вид не звучит как SW-ориентированной причине. Это приведет к тому, что ваш взгляд будет очищен от логики, а ваша модель станет связующим слоем между основным слоем и вашим слоем приложения.
Мне нравится следующий пример, касающийся модели и ее роли (почему ее не следует сочетать с VM): представьте, что вы разрабатываете приложение для Android с помощью карт Google. Карты Google - это ваше ядро. Затем в один прекрасный день вам действительно нужен вариант, скажем, цветных частей карты в розовом, ярко-розовом. Письмо в Google, запрашивающее colorPink(Map), вероятно, ни к чему не приведет. Вот где ваша модель работает и предоставляет вам оболочку карты, которую вам нужно определить для вашего мизингова метода.
Без отдельной модели вам придется проходить через каждую виртуальную машину, которая использует map и обновляет ее.

Таким образом, представление играет определенную роль, модель играет роль, VM - это логика между ними.

Edit 2:
Есть некоторые случаи, когда нет необходимости в модели слоя - я, как правило, не согласен на первый, но был убежден, после обсуждения: В относительно небольших приложений, модель может оказаться излишним без дополнительной функциональности над ядром. В таких случаях вы можете напрямую использовать основные объекты.

Answer 2

К чему он привязан? Независимо от того, что он связывает, это действительно модель представления, называете ли вы ее или нет. Если он также удваивается как модель данных, то вы нарушаете Принципа единой ответственности (SRP). По сути, проблема здесь заключается в том, что вы объединяете код, обслуживающий разные части архитектуры приложения, что приведет к запутанному беспорядку.

Answer 3

Это зависит от характера вашей модели - иногда они просты и могут служить как вы, как вы предлагаете. Однако, в зависимости от структуры, вам нужно загрязнить модель с помощью какого-либо кода события PropertyChanged, который может стать беспорядочным и отвлекающим. В более сложных случаях они служат посредником между вашим представлением и моделью. Предположим, вы создаете клиентское приложение, которое следит за удаленным процессом или записями базы данных - создавая View Model для этих объектов, давайте вам поверхности ваших данных способом, удобным для привязки к инфраструктуре пользовательского интерфейса (но глупо в структуре базы данных), инкапсулировать операции как команды, выполнить проверку и т. д. и т. д.

Answer 4

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

Гораздо проще охватить тест логикой в ​​ViewModel и оставить тестирование пользовательского интерфейса для людей. Человеческим тестерам не нужно проверять логику; их единственное сохранение должно быть пользовательским интерфейсом.

Разбирая ViewModel в иерархию ViewModels, вы можете повторно использовать ViewModel несколько раз. Не существует правила, указывающего, что для каждого представления необходимо иметь ViewModel. (После выпуска или двух я заканчиваю там, но это, кроме того, точка :))