Является ли Model-View-ViewModel лучшим шаблоном для использования в WPF? Есть ли недостатки?
Здесь хорошая короткая запись в блоге о преимуществах и недостатках MVVM, прямо от самого Джона Госсмана.
Его главными недостатками являются:
"Для простого пользовательского интерфейса MV-VM может быть излишним. В больших случаях может быть сложно спроектировать ViewModel спереди, чтобы получить нужный объем общности. Связывание данных во всех его чудесах является декларативным и сложным для отладки, чем хороший императивный материал, где вы просто установили точки останова"
Чтобы создать наше приложение, мы начали с MVVM, но после большого количества проблем мы отказались от MVVM из-за следующих причин, которые будут определять, где не использовать MVVM.
Проблема наследования
Мы программируем в .NET, и мы используем С#, и мы уверены, что хотим Наследование. С# не поддерживает множественное наследование классов, поэтому мы не можем иметь абстрактные классы с логикой, которые будут частично использоваться как в пользовательском интерфейсе, так и в логике.
В большинстве случаев нас путают, как создавать View Models, чтобы мы могли наследовать и управлять логикой.
Если мы наследуем View, мы не можем наследовать ViewModel в то же время, и если мы наследуем ViewModel, мы не можем наследовать View одновременно. Вместо этого мы должны использовать очень сложные дженерики и с помощью таких инструментов, как Prism и Unity, которых мы можем достичь, но это не стоит времени.
ViewModel для привязки к ViewModel
В большинстве случаев бизнес-логика не так проста, как A = B + C, UI и Response on UI играет огромную роль. Однако мы можем привязать визуальные свойства интерфейса к свойствам данных Model Model, но возникает вопрос о том, как фактически привязать одну модель представления к другой модели представления, и если они пройдут две привязки общих элементов управления, тогда мы не имеем представления о том, что будет выполнено первый.
ViewModel - это не простая замена CodeBehind
Предполагается, что ViewModel - простая замена файлов CodeBehind. Но при создании нашего приложения ограничение наследования учило нас, что, поскольку WPF/Silverlight поддерживает стиль пользовательского интерфейса, который может полностью отделить пользовательский интерфейс с логикой, мы просто переместили бизнес-логику в ViewModel.
Повторный код в ViewModel
В конце концов мы поняли, что мы просто пишем один и тот же код кода в каждом представлении и каждом ViewModel, изменяясь, что становится огромной болью, а поддержание - тоже болью. MVVM более подходит для разработки, основанной на тестах, но когда дело доходит до написания расширяемых компонентов, они не являются лучшим кандидатом.
WPF/Silverlight уже позволяет вам отличать код и пользовательский интерфейс очень хорошо, мы действительно разработали очень простую иерархию классов, которая выполняет бизнес-логику и дает нам все, что нам нужно. Теперь мы создаем все свойства команд на основе ICommand в качестве свойств зависимостей наших классов, которые мы связываем в UserControl, а также с Templated Control.
ICommand в CodeBehind или Template and Styles в ResourceDictionary дает нам почти все преимущества того, что мы можем получить над MVVM.
Это отличный образец и, откровенно говоря, один из немногих размытых шаблонов UI для WPF. Я имею в виду, что многие понимают и принимают его. Поэтому относительно легко получить помощь и информацию об этом.
Самый большой недостаток, на мой взгляд, заключается в том, что он увеличивает количество классов и компонентов в вашем приложении, потому что SRP trumps DRY в этом шаблоне. Сказав это, я думаю, что это того стоит.
Да, это избыток для небольших приветствий в мировом стиле.
Различные модели имеют разные сильные стороны. Люди склонны путать шаблон с реализацией. Как организованная или доступная бизнес-логика влияет на то, какой шаблон более естественен для приложения подачи. Поэтому, когда этот вопрос задает вопрос о WPF, может быть полезно прочитать три шаблона, которые трижды применялись к одному и тому же экрану в любых рамках.
Ниже приведена ссылка на статью java, в которой сравнивается MVVM ( "модель представления" ) с MVP ( "пассивное представление" ) и гибридная реализация MVVMP/MVC ( "контролирующий контроллер" ). Я считаю, что это имеет отношение к этому вопросу, поскольку у него есть раздел, который имеет сравнение шаблонов.
Он указывает на слабость, которую делает Джон Госсман, а также сравнивает как сильные стороны, так и слабости с двумя альтернативными шаблонами.