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

Question

Мне трудно решить, что думать об этом куске кода:

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

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

Answer 3

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

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