Model-View-Controller (MVC, «Модель-Представление-Контроллер», «Модель-Вид-Контроллер») — схема разделения данных приложения и управляющей логики на три отдельных компонента: модель, представление и контроллер — таким образом, что модификация каждого компонента может осуществляться независимо^[1].

• Модель (Model) предоставляет данные и реагирует на команды контроллера, изменяя своё состояние^[1].
• Представление (View) отвечает за отображение данных модели пользователю, реагируя на изменения модели^[1].
• Контроллер (Controller) интерпретирует действия пользователя, оповещая модель о необходимости изменений^[1].

MVP (Model-View-Presenter) — паттерн разработки пользовательского интерфейса. Шаблон MVP является производным от MVC, но при этом имеет несколько иной подход. Основное отличие — представление (presenter) не так сильно связано моделью (model).

Паттерн MVVM (Model-View-ViewModel) позволяет отделить логику приложения от визуальной части (представления). Данный паттерн является архитектурным, то есть он задает общую архитектуру приложения.

Данный паттерн был представлен Джоном Госсманом (John Gossman) в 2005 году как модификация шаблона Presentation Model и был первоначально нацелен на разработку приложений в WPF. И хотя сейчас данный паттерн вышел за пределы WPF и применяется в самых различных технологиях, в том числе при разработке под Android, iOS, тем не менее WPF является довольно показательной технологией, которая раскрывает возможности данного паттерна.

MVVM состоит из трех компонентов: модели (Model), модели представления (ViewModel) и представления (View).

Многоуровневая архитектура

Самый распространенный архитектурный шаблон — многоуровневая архитектура (или «n-уровневая»). Она хороша известна большинству архитекторов, проектировщиков и разработчиков. Ограничений по количеству и типу уровней никаких нет, однако в большинстве случаев такая архитектура состоит из четырех уровней: представление данных, бизнес-логика, хранение данных и база данных.

Контекст

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

Задача

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

Решение

Чтобы добиться такого разделения, при использовании многоуровневого шаблона программное обеспечение разделяется на сущности, называемые уровнями. Каждый уровень — группа модулей, предоставляющих взаимосвязанный набор сервисов. Их применение должно быть однонаправленным. Уровни полностью разделяют ПО, причем каждая часть доступна через публичный интерфейс.

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

Недостатки

Наличие уровней снижает производительность. Этот шаблон не подходит для высокопроизводительных приложений: проходить несколько уровней архитектуры для выполнения бизнес-запроса — это неэффективно.

Кроме того, добавление уровней увеличивает полную стоимость и усложняет систему.

Применение

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

Многоярусный шаблон

Контекст

При распределенном развертывании часто необходимо разделить инфраструктуру системы на отдельные подмножества.

Задача

Как разделить систему на ряд независимых в вычислительном отношении исполнительных структур — групп программного и аппаратного обеспечения, объединенных каким-нибудь средством связи?

Решение

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

Недостатки

Значительные полная стоимость и сложность.

Применение

Используется в распределенных системах.

Каналы и фильтры

Один из часто используемых шаблонов в архитектуре ПО — шаблон каналов и фильтров.

Контекст

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

Задача

Такие системы необходимо разделять на повторно используемые слабо связанные компоненты с простыми обобщенными механизмами взаимодействия — таким образом их можно будет удобно сочетать друг с другом. Слабо связанные компоненты с обобщенным взаимодействием легко использовать повторно. А поскольку они независимы, их выполнение можно запускать параллельно.

Решение

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

В таком подходе выделяют фильтры четырех видов:

• генератор (источник) — отправная точка процесса;
• преобразователь (сопоставление) — выполняет преобразование некоторых или всех данных;
• испытатель (редуцирование) — проверяет один или несколько критериев;
• потребитель (приемник) — конечная точка.

Недостатки

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

Чрезмерное использование синтаксического анализа и синтеза снижает производительность и усложняет написание самих фильтров.

Применение

Архитектура каналов и фильтров применяется в самых разных приложениях, особенно при решении задач, обеспечивающих простую одностороннюю обработку — например, инструменты EDI (электронный обмен данными), ETL (извлечение, преобразование и загрузка).

Пример — компиляторы: последовательно расположенные фильтры выполняют лексический, синтаксический, семантический анализ и создание кода.

Клиент — сервер

Контекст

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

Задача

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

Решение

В подходе «клиент — сервер» компоненты и соединительные элементы обладают определенным поведением.

• Компоненты, называемые «клиентами», отправляют запросы компоненту, называемому «сервер», и ждут ответа.
• Компонент «сервер» получает запрос от клиента и отправляет ему ответ.

Недостатки

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

Изменять принятое решение о размещении функциональных возможностей (на клиенте или на сервере) после создания системы — это обычно сложно и дорого.

Применение

Подход «клиент — сервер» можно применять в моделировании части системы, имеющей много компонентов, отправляющих запросы (это «клиенты») другому компоненту (это «сервер»), который обеспечивает работу сервисов, — например, онлайн-приложения (электронная почта, обмен документами и банковское дело).

Управляемая событиями архитектура

Контекст

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

Задача

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

Решение

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

Недостатки

Возможные проблемные области — производительность и восстановление после ошибок.

Применение

Использующее такой подход приложение для электронной коммерции будет работать следующим образом:

• Сервис «Заказы» создает Заказ в состоянии ожидания и публикует событие «Создан Заказ» OrderCreated.
• Сервис «Покупатели» получает событие и пытается зарезервировать кредит для Заказа. Затем он публикует событие «Кредит Зарезервирован» CreditReserved или «Превышен Лимит Кредита» CreditLimitExceeded.
• Сервис «Заказы» получает это событие от сервиса «Покупатели» и меняет состояние заказа на «Утвержден» или «Отменен».

Архитектура на основе микросервисов

Контекст

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

Задача

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

Решение

Создание приложений в виде наборов сервисов: каждый сервис развертывается и масштабируется независимо и имеет собственную «границу», обслуживаемую посредством API. Различные сервисы могут писаться на разных языках программирования, управлять собственными базами данных и разрабатываться разными командами.

Недостатки

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

Кроме того, потребуется больше памяти.

Применение

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

ECS

ссылка на страницу