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

Question

На странице 374 в книге Приложения Microsoft .NET для архитекторов для предприятия приведена диаграмма эволюции шаблонов для уровня представления иих влияние на платформы (рисунок 7-14).

В дополнение к демонстрации эволюции от исходного шаблона MVC к более современным вариантам, эта диаграмма также показывает, что следующие современные шаблоны могут быть применены к следующимтехнологии:

1. Модель2 (MVC)
   • Интернет только
2. Пассивное представление (MVP)
   • Веб
   • WinForms
   • WPF
3. Контролирующий контроллер (MVP)
   • Веб
   • WinForms
   • WPF
4. MVVM (модель презентации)
   • Только WPF

Примечание: Еще один недавний образец интереса, которого в последнее время нет в этом графике, - Ведущий первый (MVP) , который предполагался более подходящим для TDD.

---

Из того, что я понимаю, если кто-то разрабатывает с WPF, то шаблон MVVM является де-факто выбором (вроде как Model2 для веб-разработки),Тем не менее, кажется, ничто не мешает использовать Passive View , Supervising Controller или Presenter First в приложении WPF.Такой подход привел бы к созданию приложения, которому на самом деле все равно, является ли внешний интерфейс WPF, WinForms или Web.Похоже, что эти варианты MVP обеспечивают большую гибкость.

Однако стремление к гибкости, не зависящей от платформы пользовательского интерфейса (которая может не потребоваться), приводит к значительному усложнению разработки WPF и приводит к потерям начасть возможностей / возможностей, которые предлагает WPF?Настолько, что затраты перевешивают выгоды?

Другими словами, настолько ли велика MVVM, что не стоит рассматривать другие альтернативы в приложениях WPF?

Answer 1

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

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

Зайдя на сайт Мартина Фаулера и ища Модель презентации у нас есть

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

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

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

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

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

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

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

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

Answer 2

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

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

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

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

Поддержка

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

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

Это правда, что PassiveView лучше, когда речь идет об автоматизированном тестировании Coverege, но ИМХО, хорошая поддерживаемость кода гораздо важнее.Тестируемость помогает вам удостовериться, что вы не нарушаете свой код, в то время как Maintainability помогает вам не создавать проблемный код для начала.

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

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

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

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

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

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

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

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

Answer 3

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

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

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

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

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

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

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

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

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

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

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

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

IMO, MVPэто более логично и проще для понимания.

Недостатки

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

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

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