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

Question

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

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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