Плюсы и минусы, имеющих специфику WPF в модели представления

Question

У меня возникли проблемы, решая, что думать об этом куске кода:

public SolidColorBrush Brush 
{ 
    get { return IsValid ? _validItemBrush : _invalidItemBrush; } 
} 

Она является частью модели представления в моем текущем проекте, и как вы можете себе представить, что Brush будет привязан к некоторым текстовым элементам в пользовательском интерфейсе, чтобы указать (in) достоверность других частей данных в противном случае довольно простой и простой диалог.

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

Противники говорят, что это нарушает Разделение проблем, поскольку он четко диктует стиль, о котором следует заботиться исключительно по виду.

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

Возможно ли, что существует одно решение, которое можно было бы рассмотреть передовая практика?

Answer 1

Лично я хотел бы, чтобы две кисти были определены в XAML, и у них есть элементы управления, которые используют их кисти переключения (в xaml) на основе свойства IsValid. Это можно сделать очень легко с помощью DataTriggers или даже с одним IValueConverter - конвертер может принимать 2 кисти и логический и своп между ними довольно легко.

Это обеспечивает нейтральную презентацию бизнес-логики - «Кисть» очень специфична для конкретной формы презентации и чистого выбора. Жесткое кодирование в ViewModel нарушает принцип единой ответственности, а также не является четким разделением проблем.

Я бы очень сохранил это в представлении и переключился на свойство IsValid (связанное), специфичное для ViewModel.

Answer 2

Хотя есть обстоятельства, когда я могу использовать конструкторы WPF в модели представления, это не один из них. Вот почему:

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

• Это труднее проверить. Если вы хотите написать единичный тест, который проверяет, возвращает ли свойство правильную кисть, вы должны создать кисть в модульном тесте и сравнить значения этих двух, так как это ссылочный тип.

• Во многих, возможно, даже в большинстве случаев, это не делает код более простым или легким в обслуживании. Вы, скорее всего, уже используете стиль (предполагая, что вы знакомы со стилями), поскольку они упрощают все в WPF. Привязка IsValid к цветам кистей - это вопрос добавления стиля DataTrigger. Именно там кто-либо, поддерживающий этот код, ожидает его найти.

Есть, конечно, моменты, когда я использую WPF конструкции в модели представления - например, давно не интересно, если это была проблема, если вид модели подвергается свойство типа Visibility. Обратите внимание, что ни одна из вышеуказанных проблем не относится к этому случаю.

Answer 3

В таких случаях, как ваше, где это чисто эстетично, я использую триггеры или диспетчер визуальных состояний для изменения цветов.

Иногда я использую цвета в своих моделях ViewModels, но только если его часть моего программного обеспечения (например, цвет диаграммы, отображающей CO2 пациента, зависит от локализации). В этом случае я использую свойство struct struct struct, позволяющее View использовать Color для SolidColorBrush, GradientStop или того, что он хочет. Первоначально я использовал строку в формате #AARRGGBB, чтобы полностью удалить зависимость WPF, но моим более опытным сотрудникам это не понравилось.