Когда имеет смысл отказываться от MVVM?
Вы можете написать
@ORM\OrderBy({"date" = "ASC", "time" = "ASC"})
для нескольких критериев заказа.
4 ответа
Я еще не сталкивался с чем-либо, что невозможно было бы сделать после MVVM. Да, некоторые вещи трудны, но как только решение найдено, трудности исчезают. Каждый раз, когда вы сталкиваетесь с чем-то сложным, помните о двух ваших «больших пушках» в этом шаблоне: привязанное поведение и услуги. Когда эти две концепции находятся под вашим постоянным контролем, вы не сможете сделать с выделенным кодом ничего такого, чего не смогли бы сделать более чистым, дружественным к MVVM способом. Сложность здесь заключается просто в том, чтобы найти лучший, наиболее пригодный для повторного использования дизайн ... но это верно для любого кода.
Когда имеет смысл отказываться от MVVM? Это зависит от вашего определения отказа, но простой ответ - никогда . Если у вас есть конкретная проблема, с которой вы боретесь, и у вас нет времени, чтобы найти чистое решение, тогда лучше всего отказаться от шаблона для этой единственной проблемной области , а не полностью, как предлагает ваш пример сложности.
Когда отказ от MVVM нанесет вам вред в дальнейшем? Когда вам необходимо поддерживать приложение.
Когда отказ от MVVM не имеет значения? Демо / примеры программ, выбросить / простые утилиты и т.п.
Я не отказался от шаблона MVVM, потому что я никогда не применяю его полностью!
Из-за исторического прошлого моя компания до сих пор использует собственные библиотеки C, инкапсулированные в управляемые библиотеки, используемые в программах C # и WPF. Привязки не могут быть использованы, а некоторые поведения, такие как INotifyPropertyChanged, не могут быть реализованы, потому что изменения выполняются в каком-то глубоком методе C ... Такой глубокий рефакторинг не вариант!
Так что, с одной стороны, я понимаю, что Строгое соблюдение MVVM может быть болезненным.
С другой стороны, IMHO, я думаю, что MVVM - хороший шаблон для WPF и его следует использовать как можно чаще.
I think code-behind is fine if it's view related only. It doesn't break MVVM because it's the separation of the layers what is important. If your VMs stay unaware of the Views, then I don't think it matters if you used XAML or code. You try to minimize code-behind because it's usually cleaner and easier to do in XAML, but sometimes a few lines of code are cleaner than a lot of XAML. For example, binding all the keys of the keyboard. You can type 101 key bindings in XAML or 5 lines of code.
MVVM - это просто рекомендация. Если не нравится, то использовать не обязательно. Многие заявленные преимущества еще нуждаются в подтверждении. Но вы всегда можете позаимствовать из него несколько хороших идей.