Выступление на ADD2010: Silverlight/WPF: возврат от паттерна MVVM к MVP
- modified:
- reading: 3 minutes
Пару дней назад я упомянул, что подал тезис на конференцию разработчиков Application Developers Days 2010, которая пройдет в Ярославле 23-24 сентября. Сегодня меня обрадовали, объявили, что мой доклад прошел, его тема «Silverlight/WPF: возврат от паттерна MVVM к MVP»:
В данном докладе автор на примерах обрисует особенности реализации знаменитых паттернов MVP и MVVM, применяемых при разработке приложений на WPF и Silverlight. Даст их подробное сравнение на примере данных технологий, укажет основные плюсы и минусы реализаций данных паттернов, а так же обрисует доработанный паттерн MVP с облегченной моделью представления, который является синтезом паттернов MVP и MVVM для разработки приложений на данных технологиях.
Я уже довольно давно недоволен паттерном MVVM, а вот почему, и что я предлагаю взамен (это предложение строится на моем опыте, а так же опыте коллег-разработчиков WPF/Silverlight) я расскажу на конференции Application Developers Days 2010 в Ярославле. Доклад на 100% еще не готов, потому если есть какие-либо предложения, идеи или советы – буду рад комментариям. У меня осталась одна подписка Visual Studio 2010 Ultimate + MSDN Premium Subscription, которую, скорее всего я разыграю за интересный вопрос или предложение на конференции (если они действительно будут). Если нет, то отдам докладчику, который мне понравится своим докладом и которому она действительно нужна.
Полностью тезис можно прочитать в этом документе add.doc, основная идея доклада из тезиса ниже.
Возврат к паттерну MVP
Паттерн MVVM достаточно хорошо разрекламирован среди разработчиков Silverlight и WPF приложений, но как оказалось совершенен он не во всем. Как было описано в статье Джоша Смита, что нет смысла использовать паттерны проектирования для приложений, вроде «Hello, World!», но, к сожалению, во всех примерах реализации данного паттерна мы только такие приложения и видим, на практике же возникает больше вопросов и проблем, чем описано в подобных статьях.
Основная проблема паттерна MVVM заключается в том, что на модель представления в данном паттерне накладывает слишком много ответственности. Модель представления содержит свойства данных, которые нужно отобразить на представление, так же она же вызывает события об изменениях этих данных. Так же модель представления имеет команды, на которые перенаправляются от представления пользовательские события, обычно эти команды вызывают методы модели представления, которые содержат некоторую логику на перенаправление значений свойств данных модели представления в модель для выполнения некоторой бизнес логики в модели. Проблема становится очевидной, когда наше приложение начинает разрастаться. На модель представления накладывается больше задач, чем хотелось бы: это связывание данных с представлением и взаимодействие с моделью.
В большинстве случаев реализации MVVM паттерна модель представления имеет очень много причин для изменений. Если нам нужно на представлении поменять немного логику, использовать другое связывание данных, то, скорее всего, нужно будет менять и логику в модели представления. Если поменялась модель, то нужно менять за ней и модель представления. Одни из самых важных принципов разработки – это «разделение ответственности» (Seperation of Concerns) и «принцип единственной ответственности» (Single Responsibility Principle). В случае модели представления эти принципы нарушены.
Данную проблему можно решить, вернувшись обратно к паттерну MVP с небольшими доработками. Основой этих доработок будет являться облегченная версия модели представления, описанной Мартином Фаулером. В данном случае эта модель представления возьмет на себя только задачу связывания данных, и в некоторых случаях их валидацию. В результате у нас будет презентатор, который будет выполнять действия по запросу пользователя, модель представления, которая будет связывать данные с представлением, само представление, а так же модель. Каждый компонент фокусируется на более специфичных задачах вместо охвата нескольких, что дает нам, например, преимущества в написании тестов. Данный подход не только делает код более читабельным и классы более сфокусированными, так же у нас появляется возможность использовать облегченную версию модели представления сразу на нескольких представлениях.