Должен ли ваш ViewModel предоставлять элементы XAML как свойства или нет?

Question

В ответе на вопрос StackOverflow Как можно использовать конвертеры WPF в шаблоне MVVM? Я узнал, что конвертеры значений не следует использовать в шаблоне MVVM, начиная с функциональность преобразователя значений должна обрабатываться самой ViewModel .

Это имеет смысл.

Но я помню, что читал, что вы не должны открывать элементы XAML для представления , а вместо этого открывать только наборы данных, которые представление затем связывает и отображает с использованием DataTemplates.

Однако конвертеры кажутся достаточно мощными (например, поскольку они используются в демонстрационной программе Шаблон MVVM , см. «Образец Messenger» после распаковки)), поскольку они могут преобразовывать объекты в объекты например Объекты сообщения в объекты FlowDocument, объекты Customer в объекты Visibility или пользовательские объекты Status в изображения и т. Д.

Таким образом, если ViewModel собирается взять на себя функциональность преобразователя значений , ему придется предоставить элементы и свойства XAML, такие как StackPanel, Visibility, Color, FlowDocument и т. Д., Верно ?

Кто-нибудь видит какую-либо причину, по которой ViewModel не должен предоставлять эти расширенные объекты XAML, как это делают конвертеры значений?

Answer 1

Потому что тогда это ограничивает использование ViewModel только с определенным визуальным представлением. Если у вас есть модель ViewModel, испускающая XAML, она помещает содержимое проекта в домен разработчика. Это означает, что дизайнер, использующий Expression Blend, не может редактировать ресурсы проекта - и рабочий процесс дизайнера / разработчика нарушен. Сохранение XAML на странице и использование преобразователей значений с шаблонизацией данных позволяет отделить дизайн от кода.

Когда ваша ViewModel предоставляет конкретный XAML, это также ограничивает использование этой ViewModel только в этом конкретном экземпляре и делает его менее пригодным для повторного использования.

Answer 2

Не забывайте, что вы можете использовать DataTemplates тоже. Я вижу некоторый смысл в том, чтобы не допустить преобразование ValueConverters в MVVM, но DataTemplates - это преобразование объектов в GUI.

Ваша ViewModel может отображать другие объекты (например, вложенные ViewModels) в GUI, а GUI может использовать <DataTemplate DataType="{x:Type SubViewModel}">... для сопоставления этих объектов с GUI.

Answer 3

Кто-нибудь видит причину, по которой ViewModel не должен предоставлять эти расширенные объекты XAML, как это делают преобразователи значений?

Абсолютно, потому что это подрывает все цели MVVM:

1. Вы больше не тестируемый модуль, по крайней мере, не так просто.
2. У вас больше нет разделения между логикой (модель представления) и представлением (представление). Таким образом, дизайнеры и разработчики не могут легко сотрудничать.
3. Ведение кода сложнее, потому что вы смешали проблемы вместе.

Если бы я видел модель представления, возвращающую представление, я бы даже не классифицировал ее как MVVM.

Answer 4

Я думаю, что одной из идей mvvm / mvc / mvp и т. Д. Является изоляция кода GUI в один файл / класс. Если вы сделаете это, можете ли вы перейти на другой интерфейс без переписывания других объектов? Я думаю, что если вы передаете конкретные объекты WPF, ответ будет отрицательным. Это ценностное суждение, которое вы должны сделать для себя.

Answer 5

Не существует абсолютного правила 100%, которое бы подходило для этой или многих других концепций, когда вы обсуждаете их без учета того, почему мнение сообщества изменилось так же, как и в этом направлении. В «общепринятой мудрости» нет «предполагаемой» истины или науки, независимо от того, насколько она нова или неотразима в то время.

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