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

Ответ 1

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

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

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

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

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

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

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

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

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

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

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

Тестируемость

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

Я считаю, что Testability является менее важной из трех функций. Сортировка по важности, ее пригодность к хранению, Blendablilty и тестируемость.

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

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

Ответ 2

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

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

Переход на сайт Мартина Фаулера и поиск Модель презентации, мы имеем это

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

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

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

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

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

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

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

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

Ответ 3

Я работаю над внедрением MVP с MVVM-приложением WP7 (Silverlight) за последние пару месяцев. Я считаю, что мне удалось найти хорошее рабочее решение, которое использует лучшее из обоих миров. Недостатком является то, что есть справедливый бит кода "лесов". Потенциал роста - это MVP-структура, где уровни модели и презентатора должны быть повторно использованы между WP7, WM и Android (с учетом MonoDroid).

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

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

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

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

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

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

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

Страница/ViewModel выполняется в основном так, как вы обычно делали, однако команды - это события, которые пузырятся через ViewFacade в презентаторе.

<сильные > Преимущества

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

Простая привязка данных к MVVM.

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

Недостатки

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

Простые случаи могут иметь гораздо больше кода, чем это действительно необходимо.

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