Каковы проблемы шаблона MVVM?

Является ли Model-View-ViewModel лучшим шаблоном для использования в WPF? Есть ли недостатки?

Ответы

Ответ 1

Здесь хорошая короткая запись в блоге о преимуществах и недостатках MVVM, прямо от самого Джона Госсмана.

Его главными недостатками являются:

"Для простого пользовательского интерфейса MV-VM может быть излишним. В больших случаях может быть сложно спроектировать ViewModel спереди, чтобы получить нужный объем общности. Связывание данных во всех его чудесах является декларативным и сложным для отладки, чем хороший императивный материал, где вы просто установили точки останова"

Ответ 2

Чтобы создать наше приложение, мы начали с 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.

Ответ 3

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

Самый большой недостаток, на мой взгляд, заключается в том, что он увеличивает количество классов и компонентов в вашем приложении, потому что SRP trumps DRY в этом шаблоне. Сказав это, я думаю, что это того стоит.

Ответ 4

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

Ответ 5

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

Ниже приведена ссылка на статью java, в которой сравнивается MVVM ( "модель представления" ) с MVP ( "пассивное представление" ) и гибридная реализация MVVMP/MVC ( "контролирующий контроллер" ). Я считаю, что это имеет отношение к этому вопросу, поскольку у него есть раздел, который имеет сравнение шаблонов.

Внедрение управляемых событиями графических интерфейсов GUI с использованием инфраструктуры ZK Java AJAX

Он указывает на слабость, которую делает Джон Госсман, а также сравнивает как сильные стороны, так и слабости с двумя альтернативными шаблонами.