Всегда используйте MVVM в приложении WPF или альтернативные шаблоны все еще практичны / полезны?

Ответ @RS Conley дает очень широкое представление о предмете, и я согласен с большинством. Единственное, что я думаю иначе, так это в чистой прибыли.

MVVM - это архитектура для 95% приложений в WPF.

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

Чтобы понять, чем лучше MVVM, давайте посмотрим, что он теряет, переходя на подход PassiveView.

Ремонтопригодность

В пассивном представлении ViewModel знает о IView, что означает, что SRP (принцип единой ответственности) не сохраняется. Контроллер в PassiveView напрямую взаимодействует как с моделью, так и с представлением, и поэтому выполняет две совершенно разные вещи!.

В MVVM ViewModel, который является сердцем приложения, имеет только одну заботу: он должен содержать состояние и логику приложения. Ремонтопригодность такого кода действительно превосходит PassiveView, MVP или MVC.

Это правда, что PassiveView лучше, когда дело доходит до Coverege автоматических тестов, но IMHO, хорошая ремонтопригодность кода гораздо важнее. Возможность тестирования помогает убедиться, что вы не нарушаете свой код, в то время как ремонтопригодность помогает не создавать проблемный код с самого начала.

Когда дело доходит до ремонтопригодности, MVVM и PresentationModel являются развитием предыдущих архитектур пользовательского интерфейса, и это потому, что принцип SRP соблюдается очень строго. Напишите достаточно кода в MVVM, и вы поймете, что я имею в виду.

Смешиваемость

Еще одна особенность, в которой MVVM действительно силен, - это смешиваемость. Поскольку все состояние приложения сохраняется в ViewModel, легко подделать данные во время разработки, что позволяет значительно повысить производительность. Это невозможно создать в PassiveView, MVP или MVC, потому что во всех этих архитектурах контроллер должен активно помещать данные внутрь представления. В MVVM данные просто «перескакивают» в представление, и поэтому их можно высмеивать.

Возможность тестирования

Это действительно место, где PassiveView превосходит MVVM. Если 100% охват пользовательского интерфейса модульными тестами имеет для вас решающее значение, тогда это большое дело. Однако в большинстве ситуаций покрытия, которое позволяет вам MVVM, более чем достаточно, и вы обычно добавляете еще один уровень тестирования с использованием обычного тестирования пользовательского интерфейса (что, кстати, вы в конечном итоге будете делать в PassiveView).

Я думаю, что тестируемость - менее важная из трех функций. Отсортированные по важности, это ремонтопригодность, смешиваемость и тестируемость.

Где MVVM - неправильный выбор?

В прошлом году я участвовал в ~ 15 проектах WPF и Silverlight, все из которых идеально подходят для MVVM. Я думаю, что там, где логика представления чрезвычайно велика, например, в играх, MVVM может быть неправильным выбором. Кроме игр, я не могу придумать категорию приложений, которая не подошла бы лучше всего с MVVM, за исключением особых ситуаций, как упоминал Р.С. Конли.

Согласно прилагаемой документации в MVVM для WPF (страница 2 общего введения)

Истоки этого шаблона неясны, но, вероятно, он происходит от шаблона Smalltalk ApplicationModel, как и шаблон PresentationModel, описанный Мартином Фаулером. Команда Expression адаптировала его для использования в WPF при разработке версии 1 Blend. Без аспектов, специфичных для WPF, шаблон Model-View-ViewModel идентичен PresentationModel.

Зайдя на веб-сайт Мартина Фаулера и просмотрев модель презентации, мы увидим следующее

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

В моем собственном приложении CAD-CAM для резки металла я использую пассивный просмотр. Причины этого

1. Чтобы упростить тестирование за счет наличия фиктивных объектов, реализующих представление, что позволяет автоматически тестировать подавляющее большинство функций моего программного обеспечения.
2. Повторное использование не только базовой модели, но и различных представлений для связанных типов программного обеспечения для резки металла.
3. Чтобы четко задокументировать взаимодействие между видами и моделью.
4. Чтобы уничтожить любую зависимость от инструментария графического интерфейса пользователя, поскольку это программное обеспечение непрерывно развивается с 1985 года и претерпело несколько серьезных изменений в базовых инструментах, API и даже в самом языке.

Проблемы первых трех могут быть решены с помощью шаблона MVVM, Presentation Model, Supervising Controller. Но только пассивный вид обращался к №4.

Как заявил Мартин Фаулер, только пассивное представление не требует какого-либо метода синхронизации. MVVM - это реализация модели представления для WPF. Вы зависите от интерфейса XAML, чтобы связать состояние представления, расположенное в модели представления, с самим представлением. Поэтому, если позже вы измените пользовательский интерфейс или его API, ваша модель представления также будет изменена.

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

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

Краткий ответ на ваш вопрос о том, что MVVM - это путь для WPF, ответ - нет. Это инструмент, который необходимо рассматривать в свете других проблем, связанных с разработкой вашего приложения.

Последние пару месяцев я работал над реализацией MVP с приложением MVVM WP7 (Silverlight). Я считаю, что мне удалось найти хорошее рабочее решение, которое сочетает в себе лучшее из обоих миров. Обратной стороной является то, что существует изрядно «строительный» код. Положительным моментом является структура MVP, в которой уровни Model и Presenter должны повторно использоваться между WP7, WM и Android (с учетом MonoDroid).

Я использовал MVP-VM, как описано здесь - http://aviadezra.blogspot.com/2009/08/mvp-mvvm-winforms-data-binding.html - в качестве основы для моего дизайна.

Модель - это модель, и она не нуждается в пояснениях. Он содержит классы данных, бизнес-логику и службы и не ссылается ни на что, специфичное для пользовательского интерфейса.

Интерфейсы Presenters и View следуют шаблону пассивного просмотра.

Интерфейсы просмотра состоят в основном из событий, некоторых свойств и нескольких методов. Все, что проходит между Presenter и View, не зависит от пользовательского интерфейса.

Реализации представления представляют собой триаду из PhoneApplicationPage (или формы WPF), PageViewModel и ViewFacade.

ViewFacade - это то, что на самом деле реализует интерфейс View. Он отвечает за координацию Page и ViewModel. Он всплывает события со страницы, заставляя большинство из них запускаться асинхронно, что улавливает Presenter. Он также преобразует любые параметры событий, относящиеся к пользовательскому интерфейсу, в параметры, не относящиеся к пользовательскому интерфейсу. Все, что поступает от Presenter к ViewFacade, проверяется на безопасность потока пользовательского интерфейса и вызывается должным образом. Свойства обычно являются данными и передаются в ViewModel.

Сохранение реализации интерфейса представления (ViewFacade) отдельно от фактического класса пользовательского интерфейса (страницы, формы и т. Д.) Помогает сохранить различия между классами триады представления. Например, одна из основных задач ViewFacade - быть уровнем, на котором происходит синхронизация потоков.

Page / ViewModel выполняются в основном так же, как и вы обычно, однако команды представляют собой события, которые всплывают через ViewFacade в Presenter.

Преимущества

Дизайн MVP и возможность повторного использования между платформами.

Простое связывание данных с помощью MVVM.

IMO, MVP более логичен и легче концептуализируется.

Недостатки

Дублирование кода между событиями страницы и событиями ViewFacade, свойствами ViewModel и свойствами ViewFacade.

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

В конце концов, вы должны спросить себя, стоит ли MVP дополнительных усилий. Является ли более быстрый цикл разработки более важным, чем возможность повторного использования на разных платформах и улучшенная тестируемость?