Должен ли я иметь инкапсулирующую ViewModel для каждой модели?

Question

Я недавно работал с WPF и MVVM. У меня создалось впечатление, что я хорошо понял шаблон MVVM, но у меня возникли некоторые сомнения.

Прямо сейчас, У меня есть инкапсулирующий объект ViewModel для каждого объекта модели. Скажем, моя модель содержит два класса: Property, в котором содержится список PropertyValue. В моей модели ViewModel у меня есть PropertyVm, который содержит Property и список PropertyValueVm (каждый из которых содержит PropertyValue). Оба Vm реализуют BaseVm, который содержит метод OnPropertyChanged.

Рассмотрите представление с двумя выпадающими списками, для Property и PropertyValue. Первый выпадающий-х ItemsSource будет связан с коллекцией PropertyVms и второй выпадающий-х ItemsSource будет связан с PropertyValueVms от PropertyVm, выбранного в выпадающем списке 1.

Это все основано на статье, которая заставила меня изучить WPF и MVVM в первую очередь: Simplifying the WPF TreeView by Using the ViewModel Pattern, by Josh Smith

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

Другие реализации, с которыми я столкнулся, имеют вместо этого объекты модели INotifyPropertyChanged. Это означало бы, что вы напрямую привязываете объекты Model к Comboboxes. Это уменьшит количество классов ViewModel, но разве это не нарушает основы MVVM?

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

Итак, мой вопрос: если у меня есть инкапсулирующая ViewModel для каждой модели? Если нет, то что лучше?

Answer 1

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

Если ваша модель никогда не меняется, вы достигли религиозной развилки на дороге. Прагматик подвергает модель привязке UI (виноват !!). Пурист обертывает модель в модели представления, потому что VM сидит между M и V в дизайне, и если мы не будем догматически придерживаться этого, то, безусловно, должны произойти плохие вещи.

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