Сомнения в модели MVVM? - PullRequest
       4

Сомнения в модели MVVM?

7 голосов
/ 29 марта 2011

Я создаю приложение WPF и следую шаблону MVVM. Но, делая то, что я беспокоюсь об этом, согласно MVVM или нет? Пожалуйста, руководствуйтесь этими сомнениями.

  1. Необходимо ли иметь новую ViewModel для каждого вида? Если нет, то может ли создание единой MasterViewModel нарушать MVVM?

  2. Как ViewModels будут общаться друг с другом?

  3. MainWindow.xaml.cs, где я объединяю все виды, должна иметь только инициализацию viewmodel и назначение DataContext, или я могу также добавить другие коды?

  4. У меня есть определенные EventHandlers. Должен ли я использовать их в ViewModel или вне модели-view-viewmodel?

Ответы [ 4 ]

3 голосов
/ 29 марта 2011

Вам нужно немного почитать, чтобы заняться MVVM.См. Следующие вопросы:

Хорошие примеры шаблона MVVM
Хороший практический пример Silverlight-MVVM
Образцы MVVM Light Toolkit

На ваши вопросы:

  1. Некоторые люди следуют этому правилу.: One-ViewModel-Per-View См. Правило № 2 этой статьи .

    Совершенно необязательно следовать этому, но создание MasterViewModel для его повсеместного использования означает, что вы еще не поняли MVVM.

    Если вы имеете в виду инкапсуляцию общих бит, но, возможно, MVVM Light Toolkit имеет класс ViewModelBase для инкапсуляции нескольких вещей.

  2. ViewModels не будут взаимодействовать друг с другом, ViewModels будет взаимодействовать с представлениями, а представления будут взаимодействовать с другими представлениями (и, возможно, создавать экземпляры ViewModels для них), некоторые платформы даже имеют слабосвязанный способ сделать это ( ReactiveUI * 1030).* приходит на ум)

  3. Когда вызывается View, вы можете создать его соответствующий ViewModel и затем установить его в DataContext.Но есть много разных способов сделать это.@Euphporic упоминает в комментариях сначала ViewModel, где ViewModels создают представления через Ioc.См. Что было первым - View или ViewModel .

    MVVM Light имеет локатор ViewModel, который позволяет статически определять ViewModel Views внутри XAML.Он будет автоматически установлен при создании вашего представления.

  4. Здесь не совсем ясно, (a) Если у вас есть события из кнопок, меню, (все, что происходит от ButtonBase) вы должны реализовать их с помощью шаблона команд.MVVM Light имеет хороший RelayCommand<T>, который поможет вам здесь.

    (b) Другие события, MVVM Light имеет поведение EventToCommand, но Лоран (автор) предупреждает о том, что это превращается в Anti Pattern.Я думаю, что иногда вы можете просто использовать обычные события в вашем коде и затем вызывать ваши ViewModels оттуда (но эй, я здесь не эксперт)


Вы спрашивалипара вопросов повсюду.Возможно, проблема в том, что вы не понимаете WHY о MVVM.

Проще говоря, MVVM позволяет вам сохранить правильную вещь в нужном месте, логику / элемент управления вашего приложения во ViewModels, а затемс мощью привязки данных Silverlight / WPF вы привязываете ваши ViewModels к вашим представлениям.

Как объясняет Laurent , иногда это не должно быть настолько сложным.Вам даже не нужен фреймворк все время.

Я настоятельно рекомендую посмотреть его видео MIX под названием - "Понимание модели Model-View-ViewModel" отсюда:
http://live.visitmix.com/Archive#VideoList

2 голосов
/ 29 марта 2011

[1] Необходимо ли иметь новую ViewModel для каждого вида? Если нет, то может создать единый MasterViewModel является нарушением MVVM?

Обычно вам нужен как новый экземпляр ViewModel для каждого экземпляра View, так и отдельный класс ViewModel для каждого класса View. Иногда вам нужно несколько видов для одной и той же модели представления, что нормально. Если вы используете подход ViewModel-first, то вам не всегда нужен класс View для каждого класса ViewModel, но также не помешало бы иметь его.

[2] Как ViewModels будут общаться друг с другом?

Если ViewModels напрямую связаны (например, отношения родитель / потомок), то одна возможность для одного - иметь прямую ссылку на другого, или для одного подписаться на события другого.

Если ViewModels логически независимы, то вам следует использовать какой-то другой механизм, такой как Event Aggregator (в Prism) или Messenger (MVVM Light) или эквивалентный.

[3] MainWindow.xaml.cs, где я интегрирую все виды, должен иметь только инициализация viewmodel и назначение DataContext будет там или я тоже могу другие коды поставить?

Вы не должны инициализировать ViewModels в вашем коде View. Модели должны вводиться в представления контейнером внедрения зависимостей (DI).

[4] У меня есть определенные EventHandlers. Должен ли я использовать их в ViewModel или вне модель-вид-ViewModel?

Я не мог понять, о чем вы здесь спрашиваете.

2 голосов
/ 29 марта 2011

Необходимо ли иметь новую ViewModel для каждого View? Если нет, то может ли создание единой MasterViewModel нарушать MVVM?

Нет, у вас может быть несколько представлений для одной модели представления, хотя, как правило, имеется отношение одного представления к одному представлению. Если вы думаете об одной модели основного вида для всех видов, то она может быстро стать неуправляемой.

Как все ViewModel будут общаться друг с другом?

Существует несколько способов, в том числе прямые ссылки между моделями представления, стандартными событиями .NET или шаблоном агрегатора событий.

MainWindow.xaml.cs, где я объединяя все виды, должны иметь только инициализация viewmodel и назначение DataContext будет там или я тоже могу поставить другие коды?

Как правило, в MVVM у вас не будет (или будет очень мало) кода позади, и вы вместо этого будете использовать механизм привязки XAML в приложении WPF для связи между моделями представления / представления.

У меня есть определенные EventHandlers. Должен ли я использовать их во ViewModel или за пределами модели-вида-вида-модели?

Не совсем уверен, что вы подразумеваете под этим, но вы можете использовать стандартные события для просмотра модели связи, если требуется.

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

1 голос
/ 29 марта 2011

1. Нужно ли иметь новую ViewModel для каждого View? Если нет, то может ли создание единой MasterViewModel нарушать MVVM?

Не совсем. Вы можете иметь определенные ViewModel, которые соответствуют большому количеству представлений, каждое из которых отображает одни и те же данные в своем формате. Фактически, в этом и заключается главное обоснование MVVM - разделение отображения и бизнес-правил, так что формат отображения можно изменить путем загрузки различных представлений.

Вы также можете иметь один вид, который соответствует нескольким различным моделям представления. Это повторное использование кода в пользовательском интерфейсе дисплея.

2. Как ViewModels будут общаться друг с другом?

Обычно ViewModels взаимодействуют с Views через привязку WPF. Вот почему он называется MVVM, а не MVC.

ViewModels могут взаимодействовать друг с другом с помощью ряда стандартных средств .NET.

3. MainWindow.xaml.cs, где я объединяю все представления, должна иметь только инициализацию viewmodel и назначение DataContext, или я могу также добавить другие коды?

Вы обычно разделяете каждое представление в отдельный файл XAML. Это позволяет легко заменить другое представление для другого формата тех же данных.

Обычно рекомендуется разделять ваш код на автономные модули; то есть один просмотр одного файла, один просмотр модели одного файла.

4. У меня есть определенные EventHandlers. Должен ли я использовать их в ViewModel или вне модели-view-viewmodel?

События должны обрабатываться в представлениях, если они основаны исключительно на пользовательском интерфейсе (т. Е. Не имеют никакого отношения к данным).

Если событие должно повлиять на некоторые изменения в базовых данных (или выполнить какое-либо действие в отношении бизнес-правил), вы, в свою очередь, можете вызвать событие во ViewModel. Обратите внимание, что это событие в ViewModel может отличаться от события в View / UI.

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