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

Question

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

Answer 1

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

Модель = Business Logic

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

ViewModel = Взаимодействие Logic

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

View = Пользовательский интерфейс

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

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

Answer 2

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

Answer 3

Что касается WPF и Silverlight?

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

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

Answer 4

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

Answer 5

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

1) код становится слишком надежным.

2) MVVM отлично подходит для небольших проектов (все эти образцы hello-world во всем Интернете), но это уменьшает ваши возможности: например, события с маршрутом (отличный инструмент) все еще являются СОБЫТИЯМИ, но, как вы знаете, это строго запрещено использовать их напрямую, как только это будет code-behind), если вы хотите следовать mvvm.

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

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

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

Answer 6

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

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