MVVM WPF ViewModels для добавления нового объекта

Question

Моя концепция MVVM в WPF заключается в том, что у нас есть ViewModel для каждой модели в вашем приложении. Это означает, что если у нас есть класс (сущность) Customer, то у нас будет CustomerViewModel. CustomerViewModel будет иметь все свойства, необходимые для представления клиента. Пользовательский контроль CustomerView будет отвечать за создание пользовательского интерфейса для модели Customer.

Теперь предположим, что мы добавляем нового клиента. Итак, у нас есть форма, которая состоит из FirstName, LastName и т. Д. Нужен ли нам ViewModel для этого сценария. Я имею в виду все, что мне нужно сделать, это взять все входные значения из TextBox и создать объект Customer, а затем сохранить его в базе данных. Зачем мне создавать ViewModel для этого сценария?

Answer 1

Прежде всего, это не главная цель MVVM, чтобы «отразить» все. Представление должно обеспечивать средства для пользовательского ввода и, конечно, не обрабатывать вызовы ни к одному из уровней базы данных. ViewModel должен быть основой приложения, не зависящей от графического интерфейса, и он определенно должен обрабатывать создание клиентов.

Тем не менее, вы должны иметь ViewModel, которая представляет собой рабочее пространство для работы с клиентами, а не только ViewModel для клиентов. Если вы действительно хотите сэкономить на нескольких создаваемых объектах, добавьте в это рабочее пространство возможность создания и добавления нового клиента (не CustomerViewModel). Таким образом, вы можете иметь представление рабочей области, в котором есть элементы для каждого релевантного / обязательного свойства клиента, и, вызывая некоторые команды, добавленные в эту рабочую область ViewModel, вы можете получить текущие значения, заполненные в них (данные, связанные с ViewModel) Просмотр элементов непосредственно в модели клиента.

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

Answer 2

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

Цель ViewModel состоит в том, чтобы смоделировать вид, который он поддерживает. Это другая цель, чем моделирование идеи клиента в вашей бизнес-сфере. Сказать, что у вас будет одна ViewModel для каждой бизнес-сущности, значит, у вас будет по одному представлению для каждой бизнес-сущности, что приведет к общепринятому пользовательскому интерфейсу, ориентированному на данные.

В вашем конкретном случае подумайте о представлении редактирования клиента. Он имеет поля, которые соответствуют свойствам клиента, и, таким образом, кажется естественным для привязки к клиенту напрямую. Однако где на объекте customer смоделировано действие «Отправить»? Где смоделировано действие «Отмена»? Где моделируется, что поле X является перечисляемым значением, выбранным из списка?

Как насчет пароля? Если оно сохраняется в виде двоичного хэшированного значения, знает ли представление, как хэшировать его текст? Что если в системе установлены требования к надежности пароля?

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

Answer 3

Вам не нужно иметь отдельную ViewModel для добавления, вам нужен только один ViewModel, который должен выполнять сценарии редактирования и добавления. Если вы можете удалить запись со страницы редактирования, то эта ViewModel также должна иметь возможность удалять. Ваша ViewModel должна отражать функциональность, предоставляемую вашим представлением, независимо от данных.

Я думаю, вам следует пересмотреть вопрос о наличии единой ViewModel для каждой модели. Мне нравится думать о ViewModels как о нормализующем поведении вставленных данных. Имея ViewModel для каждого класса Model, вы рано или поздно столкнетесь с проблемами архитектуры. Я смотрю на приложение из обзора сверху вниз, что пытается выполнить мой пользовательский интерфейс, и оттуда я доберусь до ViewModel, и в конце концов я доберусь до моей DataFactory и то, как ViewModel отображает данные почти всегда не 1 к 1, кроме для самых упрощенных взглядов. Если вы попытаетесь отобразить 1 к 1, у вас будет плохой пользовательский интерфейс, или ваши данные не будут очень хорошо нормализованы.

Стек, который мы имеем здесь:

1. Просмотр
2. ViewModel (Управляет всем, что пользователь может делать в представлении, оборачивает свойства из наших POCO)
3. DataFactory (сопоставляет наши POCO с объектами Entity Framework и CRUD)
4. POCO's (Бизнес-логика, все правила и проверка)
5. Entity Framework (модель, доступ к данным)

Здесь следует отметить, что ViewModel содержит свойства из нескольких POCO!

Мы вводим DataFactory через StructureMap и модульный тест с xUnit вместе с Moq.

Чтобы ответить на второй вопрос, я бы создал отдельный вид только для просмотра, который можно было бы добавить в качестве пользовательского элемента управления. Но вы все равно должны иметь в своем приложении CRUD ViewModel, который инкапсулирует все эти функции удобным для пользователя способом.

Спасибо.

Answer 4

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

Используя обычную модель (обычный POCO), вы можете обновлять представление при изменении вашей модели, но поскольку ваша модель не реализует зависимостисвойства (скорее всего), вы не сможете воспользоваться обновлением модели, когда значение в элементе управления WPF изменится.Это значит, что вам нужно вручную добавить обработчик и скопировать это значение из этого элемента управления обратно в модель.