Когда мы используем MVVM?
Я слышал большую шумиху о MVVM для WPF.
Когда мы используем его?
Действительно ли это - использование для всего, или это только имеет определенное использование?
Действительно ли это стоит того для каждого проекта?
6 ответов
Это может быть полезно в любом проекте, но я считаю его особенно полезным в ситуациях, когда требуется четкое разделение бизнес-логики, логики взаимодействия и пользовательского интерфейса (большие приложения или приложения с участием нескольких разработчиков / дизайнеров).
Model = Business Logic
- Содержит модель любого бизнес-процесса / объекта, с которым я работаю.
ViewModel = логика взаимодействия
- Весь код, который контролирует доступ к модели и ее изменение (например, функции редактирования / отмены, отложенная загрузка и т. Д.)
View = User Interface
- Интерфейс (определенный в XAML), с которым взаимодействует пользователь. Я стараюсь свести к минимуму использование кода программной части на этом уровне, вставляя его в Attached Properties или ViewModel.
Несомненно, существует множество других применений MVVM, но именно этот сценарий я считаю наиболее полезным в моем собственном опыте разработки WPF.
Каждый раз, когда я начинаю работу над простым проектом и думаю: «Это так просто, MVVM было бы излишним», примерно через 8 часов я дохожу до точки, где Я понимаю, что использование MVVM упростит задачу.
Я бы сказал, что в большинстве случаев использование MVVM действительно упростит вашу логику пользовательского интерфейса, даже если вы изначально думаете, что это будет излишним. Проекты имеют привычку усложняться со временем, а разделение бизнес-логики и логики представления, обеспечиваемое MVVM, позволяет проекту расти гораздо более контролируемым образом, чем смешивание бизнес-логики и логики пользовательского интерфейса.
В настоящее время я работаю над большим проектом, в котором мы реализуем mvvm, CAL (руководство по составным приложениям) в Silverlight. Конечно, уровень разделения ответственности очень высок ... но
1) код становится слишком надежным.
2) MVVM отлично подходит для небольших проектов (все эти образцы hello-world по всему Интернету), но это уменьшает ваши возможности: например, маршрутизированные события (отличный инструмент) по-прежнему являются СОБЫТИЯМИ, но, как вы знаете, это строго запрещено использовать их напрямую, поскольку это код программной части), если вы хотите следовать mvvm.
3) Привязка команд ВСЕ ЕЩЕ некорректно работает в Silverlight (.net4.0, vs2010). Это долгая история, просто помните об этом сюрпризе, когда ваш делегат CanExecute не запускается при запуске приложения.
Хороший ответ на ваш вопрос: «MVVM хорош для проектов с простой логикой пользовательского интерфейса».
Спасибо, Илья.
Что касается WPF и Silverlight?
Теоретически на все - на любой нетривиальный проект (а может и то). Это часть более широкого процесса (он создает разделение проблем и позволяет проводить тестирование и другие приятные вещи). В принципе, если вы собираетесь это сделать (а я думаю, что вы, вероятно, захотите, я определенно намерен сделать это с новыми проектами), вам следует делать это практически повсеместно.
Если вы еще этого не сделали, посмотрите видео по ссылке отсюда: http://blog.lab49.com/archives/2650 - Я нашел, что это очень помогло мне понять мои идеи.
Лучше спросить: когда не следует использовать его? Самый очевидный пример - когда привязка данных не подходит, и вам нужно манипулировать элементами представления непосредственно в коде - если, например, вашему приложению необходимо обновить визуальное состояние сотен или тысяч визуальных элементов в реальном времени, вы можете не могут позволить себе накладные расходы на привязку данных.
Я нашел его полезным даже в относительно небольших проектах, если я часто использую привязку данных и объектную модель / модели данных.