Недавно я начал использовать шаблон MVVM. У меня было несколько проектов, в которых я его использовал, и каждый новый, я начинаю понимать, что он будет соответствовать этому новому проекту.
И теперь я начинаю спрашивать себя, есть ли ситуация, когда лучше использовать НЕ для использования MVVM. Или это такой хороший шаблон, который вы можете использовать где угодно?
Не могли бы вы описать несколько сценариев, где MVVM не лучший выбор?
Я могу представить два обстоятельства, при которых я не буду использовать MVVM.
Один из них, если приложение достаточно простое, что мне не требуется разделение между моделью представления и моделью. Является ли это слишком сложным для моего класса, если я реализую INotifyPropertyChanged и RelayCommand или два? Если нет, я могу пропустить шаг создания отдельного класса. Или я могу просто хотеть, чтобы модель представления смоделировала функциональный пользовательский интерфейс и беспокоилась о реализации фактических функциональных возможностей, если клиент кусает.
Другой - когда мне нужна высокая производительность, и в представлении достаточно объектов, мне нужно написать код, который напрямую управляет объектами WPF. Я на самом деле не оценил это точно, но я уверен, что рисование 1000 движущихся частиц путем итерации через массив, содержащий их, и непосредственное изменение их TranslateTransform (если это действительно самый быстрый способ их размещения) быть быстрее, чем изменять их базовые свойства и иметь привязку.
Я не MVVM, если это инструмент, который не используется больше, чем в определенный момент, а затем никогда.
Во многих "маленьких" проектах я начал без, а позже, я изменился на MVVM. Это делает проекты ИМО намного более чистыми и дает всем моим проектам аналогичную структуру. Это очень помогает мне быстро изменить некоторые вещи в каком-то старшем коде, если у клиента небольшой запрос. Я не теряю много времени для меня.
Другим преимуществом является то, что мне проще чистить мои библиотеки, потому что я могу сосредоточиться на одной технике и поэтому иметь больше времени для поддержки и расширения.
Все зависит от того, что вы хотите сделать.
Как сказали ребята, если вы создаете небольшой инструмент или проект, который не нуждается в обширном тестировании и т.д., то MVVM будет излишним.
Возможно, главным преимуществом MVVM является то, что он позволяет тестировать блок кода, поскольку он абстрагирует от Visual Layer. Для крупных проектов, которые должны быть надежными и должны использоваться клиентами и т.д. (А не только самим как конечный пользователь), тогда MVVM - хороший шаблон дизайна для использования.
Я предполагаю в двух словах - если вы просто создаете небольшой проект, чтобы запутаться, тогда MVVM будет похож на попытку yo убить ant с помощью bazooka:)
Для меня лучше не использовать его, если вы хотите сделать небольшой проект или никогда не планируете его запускать несколькими способами (WPF/Silverlight/WEB/Dll), тогда MVC достаточно.
Короткий ответ: Не используйте MVVM, если вы не используете WPF/Silverlight/любую технологию, которую я знаю, с мощным автоматическим связыванием.
Длинный ответ: Никакой другой шаблон не облегчает модульное тестирование лучше, чем MVVM в WPF/Silverlight. Я бы предложил вам взглянуть на другой ответ: Почему я должен использовать MVVM в приложении Silverlight?
Возможно, вам стоит взглянуть на Отказ от разработки MVVM на форуме Silverlight, на котором обсуждаются некоторые преимущества и недостатки MVVM.