MVVM: как представление модели должно взаимодействовать с моделью данных - PullRequest
2 голосов
/ 11 февраля 2010

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

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

Вид: ComboBox -> привязан к списку в ModelView. Представление модели связано с моделью (?????) способом. Данные, которые будут заполнять список, могут быть получены с помощью вызова веб-службы. Как работает этот сценарий?

Ответы [ 3 ]

4 голосов
/ 11 февраля 2010

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

В этом сценарии:

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

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

3 голосов
/ 11 февраля 2010

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

1 голос
/ 11 февраля 2010

Я думаю, стоит упомянуть, что вам не всегда нужны три разных класса для ваших "комбо" MVVM. V всегда будет своим собственным классом, виртуальной машине, вероятно, также понадобится свой собственный класс (хотя я не думаю, что это необходимо), но M может быть одинаковым во всем проекте, если это подходит вашему приложению. Если вы создаете небольшое приложение, скажем, у вас всего 10-15 различных методов обслуживания, вероятно, имеет смысл иметь один единственный класс, отвечающий за вызов вашего веб-сервиса, обработку ошибок и выполнение асинхронных обратных вызовов для различных виртуальных машин. , И если вы создаете действительно маленькое приложение, возможно, имеет смысл иметь только одну ВМ и, скажем, 2-3 вида, которые привязываются к этой единственной ВМ. Возможно, в этом случае вам даже не нужен отдельный класс Model, просто вызовите веб-сервис напрямую из вашей виртуальной машины. В конце концов, вы создадите сервисную ссылку на этот веб-сервис. Сгенерированные прокси-классы будут действовать как ваша Модель.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...