2010-09-08 5 views
4

Мы разрабатываем приложение WPF/MVVM, которое позволяет пользователю осуществлять поиск и манипулировать контактными записями.Как получить доступ к базовому объекту/модели ViewModel

У нас есть MainViewModel, который содержит наблюдаемую коллекцию объектов ContactViewModel, каждая из которых обертывает объект Contact, возвращенный с нашего бизнес-уровня. Пользовательский интерфейс отображает их в списке, а свойство SelectedItem привязано к соответствующему свойству SelectedContact в MainViewModel.

У нас также будет кнопка или что-то там, где команда привязана к ICommand «ProcessContact», открытому MainViewModel.

ProcessContact должен принять выбранный контакт и что-то сделать с ним, на самом деле это не имеет значения.

Мой вопрос: Каким будет правильный способ доступа к базовому объекту Contact, обернутому выбранным ContactViewModel? Я мог бы просто открыть свойство Contact в моей модели представления, но это значит, что представление может потенциально связываться с свойствами непосредственно с модели.

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

Я пропустил что-то очевидное?

Edit: Несколько предложений брошенных вокруг коллег:

  • Expose объекта в качестве охраняемой собственности на ViewModel, что бы остановить взгляд привязку к нему (если предположить, что классы вида находится в отдельном сборка)

  • Прекратите пытаться получить доступ к модели в целом. Если мы хотим каким-то образом обработать базовый объект, мы вызываем метод в ViewModel. В моем примере у нас может быть метод .Process с ContactViewModel. («SelectedContact.Process()»)

Второй вариант чувствует себя как лучшее решение для меня, но не уверен, что мы должны положить, что много логики в ViewModel (но если нет, то где?)

ответ

1

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

0

Я предлагаю иметь наблюдаемую коллекцию объектов Contact в вашем MainViewModel. Framework автоматически поддерживает уведомление об изменении свойств сущности, и вы даже не должны внедрять INotifyPropertyChanged в своей организации.

Если у вас есть какие-либо конкретные причины для обертывания вашего объекта Contact в viewmodel (мне любопытно узнать их), вам придется открыть объект Contact (через свойство ) и использовать его.

+0

Что делать, если я хочу связать, например, с фамилией контакта. Объект My Contact не поддерживает INotifyPropertyChanged (а также не должен быть бизнес-объектом POCO), но ContactViewModel * делает * и может перенаправлять обновления свойств контакту, одновременно поднимая NotifyPropertyChanged. См. Статью MVVM Джоша Смитса о msdn: http://msdn.microsoft.com/en-us/magazine/dd419663.aspx. Замените его Customer/CustomerViewModel моим Contact/CntactViewModel, и у вас будет почти такая же ситуация. –

0

Не обертывайте свою модель в свою модель ViewModel. По крайней мере, не публикуйте его как государственную собственность.

Вы можете сделать ваш докладчик наблюдателем модели, чтобы он получил уведомление при изменении модели. Ваш Ведущий может затем вызвать Вид и передать ему ViewModel.

+1

Я не думаю, что обертывание модели в ViewModel необычно в MVVM. См. Статью Джоша Смита в msdn: http://msdn.microsoft.com/en-us/magazine/dd419663.aspx, где каждый из его классов CustomerViewModel имеет ссылку на базовый объект Customer). В этом случае классы моделей являются просто контейнерами данных и не выставляют ничего, что могло бы сделать их наблюдаемыми (уведомления об изменении свойств и т. Д.), Это то, что VM там ... –

Смежные вопросы