Когда имеет смысл отказаться от MVVM?

Question

Поскольку я изучал WPF, я сосредоточился на применении только шаблона MVVM к приложениям.

Однако я замечаю, что для некоторых функций , таких как проверка , трудно или невозможно оставаться верным модели MVVM. Много раз просто добавление x: Name к элементу и изменение его в обработчике событий с выделенным кодом немедленно решает проблему.

Какой реальный опыт у вас есть с отказом от паттерна MVVM ?

• когда имеет смысл отказаться от MVVM? например Разработали ли вы правила, согласно которым, если приложение имеет определенную сложность, вы будете его использовать, иначе не будете?
• когда он отказывается от MVVM калечит вас позже (например, я могу представить, если вы хотите обновить приложение для использования библиотеки составных приложений, вся концепция внедрения ViewModels и контейнера не будет работать, если вы есть вся ваша логика в коде
• когда отменяет MVVM не имеет значения , например Я могу себе представить, что код, который вы не хотите / нужно тестировать, может просто находиться в коде, пока ваша базовая структура все еще MVVM и проходит через фиктивные тесты и т. Д.

Answer 1

Я думаю, что код-это хорошо, если это только вид, связанный. Это не нарушает MVVM, потому что важно разделение слоев. Если ваши виртуальные машины не знают о Views, я не думаю, что это имеет значение, если вы используете XAML или код. Вы пытаетесь свести к минимуму выделение кода, потому что это обычно чище и проще в XAML, но иногда несколько строк кода чище, чем многие XAML. Например, связывание всех клавиш клавиатуры. Вы можете ввести 101 привязку клавиш в XAML или 5 строк кода.

Answer 2

Я еще не сталкивался ни с чем, что невозможно сделать после MVVM. Некоторые вещи сложны, да, но как только решение найдено, трудности исчезают. Каждый раз, когда вы сталкиваетесь с чем-то сложным, помните о двух «больших орудиях» в этом паттерне: привязанное поведение и услуги. Поскольку эти две концепции находятся под вашим полным контролем, вы ничего не можете сделать с помощью кода, который вы не можете сделать более чистым, дружественным к MVVM способом. Сложность здесь заключается в том, чтобы найти лучший, наиболее многократно используемый дизайн ... но это верно для любого кода.

Когда отказ от MVVM имеет смысл? Это зависит от вашего определения отказа, но простой ответ - никогда . Если у вас есть конкретная проблема, с которой вы сталкиваетесь, и у вас нет времени, чтобы найти чистое решение, тогда прагматичным решением будет отказаться от шаблона для этой единственной проблемной области , а не полностью как от вашей. Пример сложности подсказывает.

Когда откажется от MVVM, потом тебя калечит? Когда вам нужно поддерживать приложение.

Когда не имеет значения выход из MVVM? Демо / примеры программ, одноразовые / простые утилиты и т.п.

Answer 3

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

Answer 4

Я не отказался от паттерна MVVM, потому что никогда не применяю его полностью!

Из-за исторического прошлого моя компания по-прежнему использует собственные библиотеки C, инкапсулированные в управляемые библиотеки, используемые в программах на C # и WPF. Привязки не могут быть использованы, и некоторые варианты поведения, такие как INotifyPropertyChanged, не могут быть реализованы, потому что изменения выполняются в каком-то глубоком C-методе ... Глубокий рефакторинг не вариант!

Так что, с одной стороны, я понимаю, что строго следовать MVVM может быть больно.

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