Когда мы используем MVVM?

Question

Я много слышал о MVVM для WPF.
Когда мы его используем?
Используется ли он для всего или только для определенных целей?
Стоит ли это для каждого проекта?

Answer 1

Это может быть полезно в любом проекте, но я нахожу его особенно полезным в ситуациях, когда требуется обеспечить четкое разделение между бизнес-логикой, логикой взаимодействия и пользовательским интерфейсом (большие приложения или приложения с участием нескольких разработчиков / дизайнеров).

Модель = Бизнес-логика

• Содержит модель любого бизнес-процесса / объекта, с которым я работаю.

ViewModel = Логика взаимодействия

• Весь код, управляющий доступом к модели и ее изменением (например, функциональность редактирования / отмены, отложенная загрузка и т. Д.)

Вид = Интерфейс пользователя

• Интерфейс (определенный в XAML), с которым взаимодействует пользователь. Я пытаюсь свести к минимуму использование кода в этом слое, помещая его в Attached Properties или ViewModel.

Несомненно, существует много других применений для MVVM, но этот конкретный сценарий, как я обнаружил, наиболее полезен в моем собственном опыте разработки WPF.

Answer 2

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

Answer 3

С точки зрения WPF и Silverlight?

Теоретически для всего - любой нетривиальный проект (и, возможно, даже тогда). Это часть более широкого процесса (он создает разделение интересов и позволяет проводить тестирование и другие полезные вещи). По сути, если вы собираетесь это сделать (и я думаю, что вы, вероятно, захотите, я определенно собираюсь делать это с новыми проектами), то вам следует сделать это в значительной степени по всем направлениям.

Если вы еще этого не сделали, посмотрите видео, связанное здесь: http://blog.lab49.com/archives/2650 - я нашел, что это очень полезно для разъяснения моих идей.

Answer 4

Я нашел это полезным даже в относительно небольших проектах, если я много использую привязку данных и объектную модель данных / модели.

Answer 5

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

Так что я бы сказал, что большую часть времени использование MVVM фактически упростит логику вашего интерфейса, даже если вы изначально думаете, что это будет излишним.Проекты имеют привычку усложняться с течением времени, а разделение бизнес-логики и логики представлений, обеспечиваемое MVVM, позволяет проекту развиваться гораздо более контролируемым образом, чем смешивать бизнес-логику и пользовательский интерфейс.

Answer 6

В настоящее время я работаю над крупным проектом, в котором мы реализуем mvvm, CAL (руководство по составным приложениям) в Silverlight. Конечно, уровень разделения проблем очень высок .. но

1) код становится слишком устойчивым.

2) MVVM отлично подходит для небольших проектов (все эти примеры hello-world по всему Интернету), но уменьшает ваши возможности: например, Routed events (отличный инструмент) по-прежнему EVENTS, но, как вы знаете, Категорически запрещено использовать их напрямую, как только это будет за кодом), если вы хотите следовать mvvm.

3) Привязка команд STILL не работает должным образом в Silverlight (.net4.0, vs2010). Это длинная история, просто запомните этот сюрприз, когда ваш делегат CanExecute не сработает при запуске приложения.

Хороший ответ на ваш вопрос: «MVVM хорош для проектов с простой логикой пользовательского интерфейса».

Спасибо, Илья.