Должен ли ваш 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) в графический интерфейс, а графический интерфейс может использовать <DataTemplate DataType="{x:Type SubViewModel}">... для сопоставления этих объектов в графический интерфейс.

Answer 3

  

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

Безусловно, потому что это подрывает все цели MVVM.

<Ол>

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

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

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

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

Answer 4

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

Answer 5

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

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