Область видимости MVVM ViewModel

Question

Я все еще новичок в MVVM и у меня есть вопрос.

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

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

Спасибо за любые советы.

Answer 1

Я частично согласен с @Rich и @Elad Katz. В наших приложениях мы используем MainViewModel, у которого есть свойства, которые представляют подвидовые модели. Такие как

public class MainViewMod
{
    public SomeViewModel ContentViewModel
    {
         get;
         set;
    }
    public StatusBarViewModel StatusBarViewModel
    {
         get;
         set;
    }
}

MainView получает свой DataContext из MainView. Скажем, MainView - это окно, и оно имеет <ContentControl Content="{Binding ContentViewModel}" /> и <ContentControl Content="{Binding StatusBarViewModel}" />.

Различные ContentControls "живут" где-то внутри визуального дерева MainView.

Различным ViewModel не нужно знать друг о друге. Пока у вас слабая связь между viewModels, я не вижу проблем с подмоделями. Мое эмпирическое правило заключается в том, что StatusViewModel может получить доступ к MainViewModel. В некоторых сценариях StatusViewModel может получить доступ к ContentViewModel, но только через MainViewModel, но сохранить это как минимум. Но имейте в виду, что @Elad сказал о том, что они не слишком зависят друг от друга.

Когда дело доходит до событий, мне не нужно много сценариев, чтобы получить доступ к событиям напрямую в ViewModel. Скажем, у вас есть представление, у которого есть listView, и вам нужно либо получить, либо установить выбранный элемент. В этом случае я бы добавил свойство к ViewModel, то есть SelectedItem, и связал бы это свойство с SelectedItem списка просмотра. Таким образом, вы можете получить доступ к выбранному элементу из модели представления.

Имейте в виду, что нет проблем с выделением кода для представления. В некоторых ситуациях вы должны использовать код позади. Однако я бы рекомендовал не подписываться на события в code-behind, так как их трудно найти (скажем, одно из 20 представлений имеет code-behind, не естественно заглянуть в codehind для любого представления, чтобы найти какой-либо код). там понять что происходит). Если вы используете события для элемента, либо используйте привязки команд, как указано в других ответах, либо подпишитесь на событие в XAML. В некоторых ситуациях я предпочитаю использовать прикрепленное поведение, если мне нужен доступ к модели представления.

Answer 2

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

Я на самом деле советую против того, что @Rich сказал о дочерних viewModels. Я видел такое использование много раз, и оно довольно популярно, но я думаю, что, хотя оно и поддерживает идею MVVM, оно не помогает в более широкой схеме вещей, то есть модели представления становятся зависимыми друг от друга. ViewModels должны быть максимально отделены друг от друга, как если бы они были единственным в приложении.

Answer 3

События обычно обрабатываются путем привязки к ICommand.Поскольку обычно в элементе управления имеется только ограниченный набор свойств, которые могут быть привязаны к ICommand, существуют платформы, которые позволяют динамически присоединять действия к командам, в которых в противном случае вы использовали бы событие.Я использовал AttachedCommandBehavior , и он отлично работал.Если это не сработает для вас, я уверен, что есть и другие.

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