Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

Паттерны для новичков: MVC vs MVP vs MVVM

Anna | 17.06.2014 | нет комментариев
Добрый день, уважаемые сотрудники. В этой статье я бы хотел рассказать о своем аналитическом понимании отличий паттернов MVC, MVP и MVVM. Написать эту статью меня всподвигло желание разобраться в современных подходах при разработке огромного программного обеспечения и соответствующих архитектурных особенностях. На нынешнем этапе своей карьерной лестницы я не являюсь непосредственным разработчиком, следственно статья может содержать ошибки, неточности и недопонимание. Заинтригованы, как аналитики видят, что делают программисты и архитекторы? Тогда добросердечно пожаловать под кат.

Ссылки

Первое, с чего я бы хотел начать — это ссылки на внешние материалы, которыми я руководствовался в процессе написания этой статьи:

Вступление

Во времена, когда светило светило ярче, а трава была зеленее, на тот момент команда студентов, как автор этой статьи, разрабатывали программное обеспечение, писав сотни строк кода непринужденно в интерфейсе продукта. Изредка применялись сервисы и администраторы для работы с данными и тогда решение получалось с применением паттерна Document-View. Помощь такого кода требовала грандиозных расходов, т. к. нового разработчика нужно обучить (рассказать), какой код за что в продукте отвечает, и ни о каком модульном тестировании и речи не было. Команда разработки — это 4 человека, которые сидят в одной комнате.
Прошло время, менялась работа. Разрабатываемые приложения становились огромнее и труднее, из одной сплоченной команды разработчиков стало много различных команд разработчиков, архитекторов, юзабилистов, дизайнеров и PMов. Сейчас всякий ответственен за свою область: GUI, бизнес-логика, компоненты. Возник отдел обзора, тестирования, архитектуры. Стоимость разработки ПО усилилась в сотни и даже тысячи раз. Такой подход к разработке требует присутствие упрямой архитектуры, которая бы синхронизировала различные функциональные области продукта между собой.

Паттерны

Рассматривая цель уменьшения трудозатрат на разработку трудного программного обеспечения, представим, что нужно применять готовые унифицированные решения. чай шаблонность действий облегчает коммуникацию между разработчиками, разрешает ссылаться на вестимые конструкции, снижает число ошибок.
По словам Википедии, паттерн (англ. design pattern) — повторимая архитектурная конструкция, представляющая собой решение задачи проектирования в рамках некоторого Зачастую возникающего контекста.

Начнем с первого основного – Model-View-Controller. MVC — это капитальный паттерн, тот, что обнаружил использование во многих спецтехнологиях, дал становление новым спецтехнологиям и всякий день облегчает жизнь разработчикам.

Впервой паттерн MVC возник в языке SmallTalk. Разработчики обязаны были придумать архитектурное решение, которое разрешало бы отделить графический интерфейс от бизнес логики, а бизнес логику от данных. Таким образом, в классическом варианте, MVC состоит из 3 частей, которые и дали ему наименование. Разглядим их:

Модель

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

Модель владеет следующими знаками:

  • Модель — это бизнес-логика приложения;
  • Модель владеет умениями о себе самой и не знает о контроллерах и представлениях;
  • Для некоторых планов модель — это легко слой данных (DAO, база данных, XML-файл);
  • Для других планов модель — это администратор базы данных, комплект объектов либо легко логика приложения;
Представление (View)

В обязанности Представления входит отображение данных полученных от Модели. Впрочем, представление не может напрямую влиять на модель. Дозволено говорить, что представление владеет доступом «только на чтение» к данным.

Представление владеет следующими знаками:

  • В представлении реализуется отображение данных, которые получаются от модели любым методом;
  • В некоторых случаях, представление может иметь код, тот, что реализует некоторую бизнес-логику.

Примеры представления: HTML-страница, WPF форма, Windows Form.

Отличия MVP & MVVM & MVP

Особенно распространенные виды MVC-паттерна, это:

  • Model-View-Controller
  • Model-View-Presenter
  • Model-View-View Model

Разглядим и сравним всякий из них.

Model-View-Presenter


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

Знаки презентера:

  • Двухсторонняя коммуникация с представлением;
  • Представление взаимодействует напрямую с презентером, путем вызова соответствующих функций либо событий экземпляра презентера;
  • Презентер взаимодействует с View путем применения особого интерфейса, реализованного представлением;
  • Один экземпляр презентера связан с одним отображением.

Реализация:
Всякое представление должно реализовывать соответствующий интерфейс. Интерфейс представления определяет комплект функций и событий, нужных для взаимодействия с пользователем (скажем,IView.ShowErrorMessage(string msg)). Презентер должен иметь ссылку на реализацию соответствующего интерфейса, которую традиционно передают в конструкторе.
Логика представления должна иметь ссылку на экземпляр презентера. Все события представления передаются для обработки в презентер и фактически никогда не обрабатываются логикой представления (в т.ч. создания других представлений).

Пример применения: Windows Forms.

Model-View-View Model


Данный подход разрешает объединять элементы представления со свойствами и событиями View-модели. Дозволено утверждать, что всякий слой этого паттерна не знает о существовании иного слоя.

Знаки View-модели:

  • Двухсторонняя коммуникация с представлением;
  • View-модель — это абстракция представления. Традиционно обозначает, что свойства представления совпадают со свойствами View-модели / модели
  • View-модель не имеет ссылки на интерфейс представления (IView). Метаморфоза состояния View-модели механически изменяет представление и напротив, от того что применяется механизм связывания данных (Bindings)
  • Один экземпляр View-модели связан с одним отображением.

Реализация:
При применении этого паттерна, представление не реализует соответствующий интерфейс (IView).
Представление должно иметь ссылку на источник данных (DataContex), которым в данном случае является View-модель. Элементы представления связаны (Bind) с соответствующими свойствами и событиями View-модели.
В свою очередь, View-модель реализует особый интерфейс, тот, что применяется для механического обновления элементов представления. Примером такого интерфейса в WPF может быть INotifyPropertyChanged.

Пример применения: WPF

Model-View-Controller


Основная идея этого паттерна в том, что и контроллер и представление зависят от модели, но модель никак не зависит от этих 2-х компонент.

Знаки контроллера

  • Контроллер определяет, какие представление должно быть отображено в данный момент;
  • События представления могут повлиять только на контроллер.контроллер может повлиять на модель и определить другое представление.
  • Допустимо несколько представлений только для одного контроллера;

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

Пример применения: MVC ASP.NET

Резюме

Реализация MVVM и MVP-паттернов, на 1-й взор, выглядит довольно примитивный схожей. Впрочем, для MVVM связывание представления с View-моделью осуществляется механически, а для MVP — нужно программировать
MVC, по-видимому, имеет огромнее вероятностей по управлению представлением.

Всеобщие правила выбора паттерна
MVVM
  • Применяется в обстановки, когда допустимо связывание данных без необходимости ввода особых интерфейсов представления (т.е. отсутствует надобность реализовывать IView);
  • Частым примером является спецтехнология WPF.
MVP
  • Применяется в обстановки, когда немыслимо связывание данных (невозможно применять Binding);
  • Частым примером может быть применение Windows Forms.
MVC
  • Применяется в обстановки, когда связь между представление и другими частями приложения немыслима (и Вы не можете применять MVVM либо MVP);
  • Частым примером применения может служить ASP.NET MVC.
Завершение

В завершении, автор этой статьи хотел бы подметить, что сурово придерживаться только одному паттерну — не неизменно наилучший выбор. Скажем, представьте, что Вы хотели бы применять MVVM для разработки приложений с применением Windows Forms через качество контролов Bindings. Ваша цель — это отделить представление от бизнес логики и логики, которая их объединяет. Приложение должно быть легко тестируемым и поддерживаемым, а для аналитиков — внятным (чай на вопрос «в чем измеряется работа жесткого диска» существует исключительный верный результат — в Джоулях (отвлеченный пример Модели -> Представления)).

Огромное спасибо за уделенное время, славного чтения!

Источник: programmingmaster.ru
Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB