Избегать привязки MVVM / данных для небольших окон?

Question

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

Позвольте мне привести простой пример из реальной жизни, который я недавно имел: диалоговое окно с двумя кнопками (с фиксированным текстом) и настраиваемым текстовым блоком.

1. Используя простую старую технику программирования на основе кода x:Name, это вопрос нескольких строк кода (установить текст, обработать два нажатия кнопки, вернув значение и закрыв окно) - - чисто и просто.

2. Выполнение этого «рекомендуемого способа», т. Е. Создание класса модели представления (реализация INotifyPropertyChanged или наследование DependencyObject) и определение команд, требует огромного количества кода по сравнению с решением, приведенным выше (тем более что краткого пути определить "локальная переменная + свойство + поднять PropertyChanged" в VB), что делает решение менее читабельным и более подверженным ошибкам.

Итак, в настоящее время я использую прагматичный подход выбора между «простым старым x: Name» и моделью представления в каждом конкретном случае. Однако большое количество сообщений в блогах и на форумах, утверждающих, что модель представления должна использоваться постоянно, заставляет задуматься, не упустил ли я что-то из виду.

Я что-то упустил?

Answer 1

Я все для MVVM, но окно, которое вы описываете, может быть реализовано один раз и затем заполнено по мере необходимости, если вы хотите открыть его. Таким образом, ViewModel может выглядеть так:

public SmallDialogTask
{
    string Title { get; set; }
    string Text { get; set; }
    string AcceptButtonLabel { get; set; }
    string RejectButtonLabel { get; set; }

    Command AcceptCommand { get; }
    Command RejectCommand { get; }
}

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

См. Также DRY , мой вопрос о диалогах MVVM и - просто для справки - мой пост в блоге о MVVM .

Answer 2

Вы можете использовать привязку данных без определения модели представления - и в большинстве «маленьких» окон нет сложной логики - так что вам на самом деле не нужно уведомление об изменении.

Просто установите DataContext = this и привязку данных к свойствам класса окна.

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

(я также думаю, что MVVM излишен для многих не очень маленьких окон, но я, очевидно, в этом меньшинство)

Answer 3

Вам не нужно реализовывать INotifyPropertyChanged в классе модели представления. Это нужно делать только в том случае, если вам нужно уведомление об изменении, а для простых диалогов - нет.

Я не могу говорить о специфичных для VB проблемах, но в C # полученный код по крайней мере настолько же прост и лаконичен, насколько это было бы, если бы он жил в коде позади окна - и часто даже больше, если вы пытаетесь реализовать командное поведение без реализации команд. («Я просто установлю IsEnabled на true в этом установщике свойств, чтобы кнопка« ОК »была включена после ввода данных», - это одно из тех предложений, в которых слово «просто» оказывается чертовой ложью .)

Контраргумент этого - «конечно, но если я не реализую уведомление об изменении, то я не могу выполнять X и Y, когда что-то меняет значение свойства» - подрывает утверждение, что то, что вы создаете, просто.

Я считаю, что в общем, все не так просто, как я думаю, что будет, когда я впервые запустил его. Гораздо проще добавить уведомление об изменении и команды к классу модели представления, чем реорганизовать класс модели представления из кода окна, чтобы я мог добавить к нему уведомление об изменении и команды.

Наконец, если вы используете классы моделей простых представлений для поддержки простых представлений во всех случаях, кроме одного, этот один случай когда-нибудь укусит вас (или другого разработчика) в задницу. Многое можно сказать о последовательности, если стоимость последовательности низкая.

Answer 4

Я делаю нечто подобное, однако в ситуациях, когда мне просто нужно очень маленькое окно, которое делает что-то очень простое, я, по крайней мере, реализую интерфейс и вызываю его через шлюз, чтобы я мог вызывать его тестируемым способом. Примерно так:

// напр. в viewmodel.cs или command.cs

var sometextIwantUserToEnter = UIServices.GetMeSomethingThatCan().GetText();

Мое окно будет реализовывать IGetText, и я делаю все показы окна и проверку результатов в самом окне в методе GetText. Это сохраняет все изолированное в окне, и я могу утверждать, что служба была вызвана в моих тестах.

Надеюсь, что это имело смысл.

Answer 5

Я делаю то же самое.

Небольшие диалоги и быстрый выбор или информационные сообщения просто выполняются самым простым способом. Я стараюсь не слишком усложнять вещи ненужными шаблонами. Основные окна приложения и все, что больше, обычно делается с помощью MVVM.

(Значит, либо вы ничего не пропустили, либо я пропустил то же самое.)