Архітектура візерунком
Організація шаблону архітектури та взаємодія між компонентами
Класифікація Існують різні шаблони архітектури, які розумно використовуються залежно від обсягу проекту та середовища: Model-View-Controller, Model-View-ViewModel Багаторівнева та шарова архітектура, розподілені системи, Доменний дизайн, Гексагональна архітектурна веб-зона, JavaEE,. -Серверно-орієнтований (орієнтований на процес), одноранговий. Розширений клієнт, додаток графічного інтерфейсу Внутрішня структура програмних компонентів Відображення, Інверсія управління, Введення залежностей. Адаптивні (компонентні) системи, роз'єднання
Контролер перегляду моделі Контроль презентації моделі
Проблема/середовище Різні користувачі або подання одних і тих же даних Перегляд 1: Кругова діаграма ASD: ASD: 95 95 CJA: CJA: 64 64 FBU: FBU: 109 109 JPQ: JPQ: 152 152 SGD: SGD: 204 204 Перегляд 2: Гістограма ASD 95 15% CJA 64 10% FBU 109 JPQ 152 18% SGD 33% 204 24% View 3: Spread Sheet
Проблема/Середовище Для представлення моделі генерується один або кілька подань. Кожен вигляд повинен гарантувати, що він правильно відображає поточний стан моделі. Рішення: Спостерігач Кожен погляд реєструється з моделлю як спостерігач. Коли модель змінюється, вона повідомляє всіх спостерігачів. Це дає поглядам можливість адаптуватися. Проблема: події користувача
Модель-View-Controller Три частини Вивід користувача Введення користувачем Модель View View Controller View Controller Контролер Модель Модель Дані моделі та їх обробка Презентація даних Введення користувачем Роз'єднання різних частин програми більша гнучкість
Перегляд Відображає дані/інформацію (презентація) Переадресація введення користувачем контролера Знає контролер та модель Інформується про зміни даних моделлю (спостерігачем)
Контролер Керує одним або, можливо, декількома поданнями. Отримує дії користувача (події) із представлення та оцінює їх. Передає дії моделі. Модель може бути поінформована про зміни даних (спостерігач), щоб реагувати на зміни статусу. Може керувати видом (змінити вид, змінити на іншу сторінку)
Модель Функціональна частина програми. Відповідальна за управління даними та бізнес-логіку. Observable Знає зареєстрованих спостерігачів (подання та контролери). Повідомляє всіх спостерігачів про зміни даних або стану
MVC із спостерігачем/спостерігачем
Обробка подій за шаблоном MVC
Посилання на інші візерунки Observer Якщо в MVC зазвичай використовується презентатор представлення моделі, подання діє лише у режимі презентації, це зв'язок між моделлю та видом керує логічними процесами між двома іншими. Модель View ViewModel MVP з прив'язкою команд і даних
Відкриті точки Розподіл логіки між контролером та моделлю? Урегулювання форматування та інтернаціоналізації? Місце для перевірки введення користувачем? Вирішуються по-різному в різних реалізаціях/фреймворках.
Вид подання моделі Модель прив'язки даних/Презентація подання моделі
Навколишнє середовище/призначення Аналогічно шаблону MVC Поділ представлення та логіки Спрощення інтерфейсу за допомогою прив'язки даних
Розділення властивостей на окремі частини Вигляд інкапсулює структуру інтерфейсу користувача (наприклад, HTML5). ViewModel інкапсулює логіку презентації. Модель інкапсулює бізнес-логіку та її дані. View взаємодіє з ViewModel вільною зв'язкою за допомогою прив'язки даних та подій
Перегляд Відображає дані/інформацію (презентація) Отримує дії користувача. Чи не ViewModel знає модель? Не несе відповідальності за обробку даних користувачів. Визначає прив'язку даних та команд до ViewModel. В ідеалі він не містить жодної ділової логіки.
Модель містить дані та бізнес-логіку. За потреби отримує доступ до серверної бази. Незалежно від презентації (View) та контролю (ViewModel). Відповідає за дані та методи обробки даних (CRUD-операції).
ViewModel Надає дані з моделі та команди для (одного) подання. Реалізує логіку дії подання. Знає модель, але не вигляд (лише за допомогою прив'язки даних). Підпишіться на модель як спостерігач. Повідомляється про зміни в моделі.
Приклад: Angular Джерело: https://angular.io/guide/architecture
Приклад: Кутовий (View та ViewModel) Вид:
список героїв
виберіть героя зі списку
Переваги Більш простий вигляд (майже не має GlueCode) Легко обмінюється Строгий розділення дизайну та логіки Хороша перевірочність Прив'язка даних Перегляд автоматично оновлюється Недоліки Більша складність Двосторонній спостерігач Високі обчислювальні зусилля
Додаток MVVM використовується в XAML/WPF JavaFX HTML5 (HTML/JavaScript, наприклад, Angular, Knockout.).
Багаторівнева та багатошарова архітектура
Архітектура багаторівневого середовища - це шаблон архітектури, в якому додаток розділено на кілька незалежних рівнів (рівнів), які є окремими екземплярами середовища виконання. Візерунок архітектури багатошарової архітектури також ділить додаток на кілька шарів, які, однак, як правило, не всі незалежні та окремі екземпляри середовища виконання. В обох випадках виклик завжди надходить від «вищого» до «нижчого» рівня/рівня. Модель - це модель рівня OSI (теорія операційної системи).
Категорія/призначення шаруватої архітектури Архітектура шарів - це часто використовуваний принцип структурування. Архітектура шарів зменшує складність залежностей у системі Чіткий розподіл завдань Низькозв'язувальні шари запобігають циклам у графіку залежностей Шари добре зрозумілі (через їх чітко визначене завдання).
Категорія/призначення багаторівневої архітектури Розділення програми на кілька модулів виконання з чітко визначеними завданнями дозволяє масштабувати програму відповідно до вимог. Кожен рівень має своє чітке завдання: Чіткий розподіл завдань Трирівнева архітектура низького зв’язку: Розділення програми на: Клієнта (наприклад, клієнт JavaScript, працює в браузері користувача) Сервер (бізнес-логіка, працює на сервері X або в хмарі) База даних (постійність, працює на сервері Y або в хмарі) Багаторівнева архітектура вимагає використання шарів, але не навпаки.
Приклад багатошарової архітектури Джерело: довідкова архітектура програмного забезпечення FDJP
Приклад багаторівневої архітектури Джерело: https://www.lucidchart.com/pages/uml/deployment-diagram
Переваги багаторівневої/багатошарової архітектури Багаторівневі архітектури легко масштабуються та мають високий ступінь гнучкості. Окремі рівні, відповідно Шари легко взаємозамінні. Якщо інтерфейси/інтерфейси змінені, лише два сусідні рівні відповідають. Уражені шари. Багаторівневі архітектури інкапсулюють залежності машин і тому їх легко переносити. Багаторівневі архітектури дозволяють локальний розподіл рівнів (висока доступність, управління ризиками стихійних лих)
Масштабованість Масштабування, як правило, можливе лише за допомогою дорогого обладнання. Багаторівнева архітектура, як правило, є необхідною умовою масштабування. У хмарі масштабування - це стандартна хмара, яка може динамічно масштабуватися залежно від навантаження Багаторівневість, а отже, багатошарова архітектура є стандартом для сьогоднішнього бізнесу Програми.
Недоліки Часто буває складно акуратно структурувати системи пошарово. Між шарами потрібні додаткові класи/інтерфейси або навіть віддалені інтерфейси. Додаткові накладні витрати через поділ на шари (пересилання повідомлень)
Використання багаторівневих та багаторівневих архітектур є вигідним, коли потрібна висока масштабованість та гнучкість програми. обмін окремими шарами повинен бути легким. Інтерфейси залишаються стабільними (стандартні інтерфейси). Компоненти та апаратні/програмні платформи повинні бути взаємозамінними. Апаратні/програмні платформи купуються в хмарі. повинна бути можливість подальшого розподілу компонентів зі складною функціональністю. система повинна створюватися кількома командами з чіткими обов'язками.