Когда НЕ использовать MVVM?

Question

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

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

Не могли бы вы описать несколько сценариев, когда MVVM не был бы лучшим выбором?

Answer 1

Я могу вспомнить два обстоятельства, при которых я бы не использовал MVVM.

Во-первых, если приложение достаточно простое, мне не нужно разделять модель представления и модель. Не слишком ли это портит мой класс, если я реализую INotifyPropertyChanged и RelayCommand или два? Если нет, я мог бы пропустить шаг создания отдельного класса. Или я могу просто захотеть, чтобы модель представления смоделировала функциональный пользовательский интерфейс и беспокоилась о реализации реальных внутренних функций, если клиент кусается.

Другой случай, когда мне нужна достаточно высокая производительность, и в представлении достаточно объектов, и мне нужно написать код, который напрямую манипулирует объектами WPF. Я на самом деле не тестировал его, чтобы быть уверенным, но я уверен, что рисование 1000 движущихся частиц путем итерации по массиву, содержащему их, и непосредственное изменение их TranslateTransform (если это действительно самый быстрый способ их позиционирования) быть быстрее, чем изменять их базовые свойства и делать привязки.

Answer 2

Я не использую MVVM, только если это инструмент, который не используется чаще, чем в определенный момент, а затем никогда.

Во многих «маленьких» проектах я начинал без, а позже я перешел на MVVM.Это делает проекты IMO намного более чистыми и дает всем моим проектам похожую структуру.Это очень помогает мне быстро изменить некоторые вещи в старом коде, если у клиента небольшой запрос.Я не теряю много времени, чтобы ориентироваться.

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

Answer 3

Все зависит от того, что вы хотите сделать.

Как сказали ребята, если вы создаете небольшой инструмент или проект, который не требует обширного тестирования и т. Д., Тогда MVVM будет излишним.

Возможно, основным преимуществом MVVM является то, что он делает тестируемый блок кода абстрагированным от визуального уровня.Для больших проектов, которые должны быть надежными и использоваться клиентами и т. Д. (А не только вами как конечным пользователем), MVVM - это хороший шаблон проектирования для использования.

Я думаю, в двух словах - если вы просто создаете небольшой проект, чтобы возиться с ним, тогда MVVM будет все равно что пытаться убить муравья с помощью базуки:)

Answer 4

Для меня лучше не использовать его, когда вы хотите сделать небольшой проект или никогда не планируете запускать его несколькими способами (WPF / Silverlight / WEB / Dll), тогда MVC достаточно.

Answer 5

Краткий ответ: Не используйте MVVM, если вы не используете WPF / Silverlight / какие-либо технологии, известные мне с мощным автоматическим связыванием.

Длинный ответ: Никакой другой шаблон не облегчает модульное тестирование лучше, чем MVVM в WPF / Silverlight.Я бы посоветовал вам взглянуть на другой мой ответ: Почему я должен использовать MVVM в приложении Silverlight?

Answer 6

Возможно, вы захотите взглянуть на Рассказ о разработке MVVM на форуме Silverlight, где обсуждаются некоторые преимущества и недостатки MVVM.