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

Question

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

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

Answer 1

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

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

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

Answer 2

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

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

Стек мы имеем здесь:

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

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

Мы вводим DataFactory через StructureMap и Unit test с помощью xUnit вместе с Moq.

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

Спасибо.

Answer 3

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

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

Answer 4

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

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

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

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

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