Предоставьте список моделей нескольким моделям представления и синхронизируйте их - PullRequest
0 голосов
/ 07 ноября 2010

Я знаю, что существует множество дискуссий о том, как следует обрабатывать коллекции Model и ViewModel, и было предложено множество «синхронизирующих» решений от разных сторон наряду с BLINQ, CLINQ, MVVM Wrapper Kit и т. Д. Я до сих пор не понимаюэто и я хотел бы найти хорошее решение проблем в моем текущем проекте, как описано здесь.Основное отличие состоит в том, что у меня есть несколько моделей ViewModel, которые предоставляют одни и те же данные модели.

У меня довольно простой проект WP7, и я использую MVVM Light и класс Messenger в качестве посредника.Существует список элементов, которые извлекаются из изолированного хранилища.Несколько (четыре) разных представлений показывают эти данные в разных формах.Все три из них могут изменять данные по-разному (ViewModel содержит логику для изменения, а не представление).

Если я использую ObservableCollection <> в ViewModel, которая упаковывает List <> взатем модель ViewModel, которая изменяет данные, изменяет как свою собственную ObservableCollection <>, так и List <> в модели.Это, вероятно, то, что я сделал бы, если бы у меня была одна ViewModel, предоставляющая список из модели, чтобы ViewModel могла поддерживать себя и модель в актуальном состоянии.Однако в этом проекте у меня несколько потребителей в одном и том же списке, и ObservableCollections <> в других моделях представления не будут обновлены.Чтобы исправить эту ситуацию, я могу использовать шаблон-посредник и уведомить другие модели ViewModels об изменении коллекции элементов, чтобы они могли обновить ее.Я мог бы добиться некоторой производительности, отправив сообщение, описывающее изменение, и все другие модели ViewMode могли бы сделать то же самое внутренне.Это, однако, потребовало бы, чтобы я разделял некоторые из этой логики в центральном месте, чтобы избежать дублирования логики добавления / удаления / изменения в нескольких разных моделях ViewMode.

Поскольку мне нужно сообщить об изменениях другим моделям ViewM, я решил пойтидругой маршрут.Я изменил ObservableCollection <> на стандартный список <> и удалил код для обработки уведомлений об изменениях.Таким образом, и ViewModel, и Model имеют объекты List <>.На самом деле не имеет значения, обертываю ли я список моделей в ViewModel или нет, я могу выставить Model.Items непосредственно в ViewModel, чтобы упростить вещи (и, возможно, получить некоторую производительность).Теперь, когда какая-то модель ViewModel что-то изменит, она изменит ее непосредственно в модели, а затем отправит сообщение о том, что коллекция элементов изменилась, и все модели ViewModel вызывают уведомление об изменении свойства для свойства коллекции.

Кажется, это работает нормально,У меня есть две проблемы:

  • Это хорошее решение или у меня будут проблемы позже?Я делаю что-то полностью против MVVM, что в долгосрочной перспективе повредит кодовой базе?
  • У меня такое ощущение, что время от времени уведомления об изменениях бывают немного медленными.То есть, когда я «нажимаю» на элемент в списке, перед его обновлением происходит небольшая задержка.Я не уверен, что это потому, что я обновляю весь список i в нескольких представлениях или из-за задержки посредника.

Любые мысли / комментарии приветствуются.

Ответы [ 2 ]

1 голос
/ 08 ноября 2010

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

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

0 голосов
/ 08 ноября 2010

Часть решения о том, что делать в этой ситуации, будет зависеть от количества объектов в вашем Списке и количества манипуляций с ними.Какой бы подход вы ни выбрали, обязательно проведите тщательное тестирование на реальном устройстве для проверки производительности.

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

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

...