Передача данных на уровень данных

Question

Моя модель состоит из одного основного объекта, в который пользователь может добавлять различные другие объекты.Добавленные объекты хранятся в List<object>, содержащемся в главном объекте, и связанных с ним дочерних объектах.

Так что, если проект представляет собой дом.Пользователь может добавить в дом несколько Room объектов, которые хранятся в List<Room> RoomList.Тогда каждый Room может иметь добавленное число Furnishings, вновь сохраненное в каждой комнате List<Furnishing> FurnishingsList

Вопрос в том, как реализовать это в подходе MVVM?Когда пользователь добавляет новый объект, могу ли я добавить его в ObservableCollection в ViewModel, чтобы обновить представление, и в то же время добавить его в модель, подключенную к виртуальной машине?Или я сохраняю его в ВМ до команды сохранения или фиксации, а затем передаю его в модель?

В моем примере у меня есть различные редакторы (каждый из которых является пользовательским элементом управления).Таким образом, пользователь может редактировать дом на высоком уровне, используя один редактор для добавления, редактирования и удаления комнат из дома.И на более низком уровне, используя разные редакторы для редактирования каждой комнаты, добавляя и удаляя Furnishings.

Поэтому, когда пользователь «Редактирует» комнату, говорят.Я произвожу EditRoomModelView, содержащий указанное Room.Пользователь добавляет, редактирует и иным образом манипулирует обстановкой в ​​этой комнате.

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

Извинения за бессвязный подход, изо всех сил пытаюсь найти хороший подход к этому, любой понимает, что яклоню?

Answer 1

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

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

Итак, учитывая все это, я могу рассказать вам, как лично я предпочитаю подходить к этой проблеме (в частности, к проблеме добавления, которую вы упоминаете).Мне обычно нравится создавать модели представления, которые описывают проблемы пользователей с помощью обобщений, таких как EditItemViewModel<T> или ListViewModel<T>.Таким образом, в графическом интерфейсе будет какой-то список комнат, привязанных к ListViewModel<Room>.Эта виртуальная машина, очевидно, будет предоставлять видимую коллекцию, а также команды для добавления, удаления, редактирования.

Итак, с моей точки зрения, уровень представления, моделирующее представление, которое собирается делать эта виртуальная машина, - это маршрутизация запросов для других проблем с графическим интерфейсом.Если вы нажмете «Добавить», чтобы добавить комнату, эта виртуальная машина будет отвечать за инициирование запроса с помощью команды для любого экрана / окна / всего, что необходимо для добавления комнаты, которая будет иметь свою собственную виртуальную машину.Эта виртуальная машина, получив запрос на добавление, передаст сгенерированный объект передачи данных в домен, где произойдет валидация, и все необходимые операции домена.Я обычно справляюсь с этим через сервисный слой.Теперь, если операция с доменом прошла успешно, сервисный уровень вызовет какой-то четный или обратный вызов, чтобы сообщить виртуальной машине списка, что произошли изменения.Когда это происходит, виртуальная машина списка повторно запрашивает свой сервис и соответственно обновляет свою наблюдаемую коллекцию.Теперь ваш графический интерфейс совместим с доменом по всем направлениям.

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

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

Answer 2

Из приложения, которое вы описываете, звучит так, будто ваш слой модели представления не изменяет и не формирует вашу модель значительно. Итак, я бы сделал различные установщики / получатели свойств модели представления простыми адаптерами для обернутых объектов модели. Таким образом, ваша модель будет обновлена ​​сразу после изменения модели представления.

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

Время, когда вы фиксируете слой модели, редко имеет большое значение, потому что обычно это не длительный процесс. Что более важно, так это когда состояние модели сохраняется. Это часто вызывается явным вызовом команды сохранения, которая отправляет модель в службу сохранения (файл / облако и т. Д.)

Answer 3

Первое: View - это зеркало вашего DataModel, поэтому всегда добавьте сначала к Model и только после подумайте, если он нажмет Vm или на View.

Второе: ViewModel - это мост, который соединяет ваш Model с View, но не означает, что он должен быть структурирован таким же образом, как было сделано Model. Если вы хотите показать пользователю все дочерние коллекции, вы должны представить их как свойства и сконструировать их внутреннее отношение parent-child в VM или в VM, иметь только «сырые» коллекции и иметь эффективные отношения между ними в DataModel.