Архитектурен модел
Организация на архитектурния модел и взаимодействие между компонентите
Класификация Съществуват голямо разнообразие от архитектурни модели, които се използват разумно в зависимост от обхвата и средата на проекта: Model-View-Controller, Model-View-ViewModel Архитектура на много нива и слоеве, разпределени системи, Domain Driven Design, Hexagonal Architecture Web Area, JavaEE, .Net, Client -Сървър ориентиран към услугата (ориентиран към процеса), peer-to-peer. Rich Client, GUI приложение Вътрешна структура на софтуерните компоненти Отражение, Инверсия на управление, Инжектиране на зависимост. Адаптивни (компонентни) системи, отделяне
Контролер на изглед на модел Контрол на представянето на модел
Проблем/среда Различни потребители или изгледи на едни и същи данни Изглед 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% Преглед 3: Разпръснат лист
Проблем/среда За представяне на модел се генерират един или повече изгледи. Всеки изглед трябва да гарантира, че той правилно отразява текущото състояние на модела. Решение: Наблюдател Всеки изглед се регистрира с модела като наблюдател. Когато моделът се промени, той уведомява всички наблюдатели. Това дава възможност на гледните точки да се адаптират. Проблем: потребителски събития
Модел-View-Controller Три части Изход за потребител Въвеждане на потребител Модел View Controller View Controller Controller Модел на модела Данни на модела и тяхната обработка Представяне на данните Потребителски вход Отделяне на различните части на приложението повече гъвкавост
Изглед Показва данните/информацията (презентация) Препраща потребителски вход към контролера Познава контролера и модела Информира се за промените в данните от модела (наблюдател)
Контролерът управлява един или евентуално няколко изгледа.Получава потребителски действия (събития) от изгледа и ги оценява. Препраща действията към модела.Моделът може да информира за промени в данните (наблюдател), за да реагира на промени в състоянието. Може да контролира изгледа (промяна на изгледа, промяна на друга страница)
Модел Функционалната част на приложението. Отговаря за управлението на данните и бизнес логиката. Наблюдаем Познава регистрираните наблюдатели (изгледи и контролери). Уведомява всички наблюдатели за промени в данните или състоянието
MVC с наблюдаем/наблюдател
Обработка на събития в шаблона на MVC
Препратка към други модели Observer Ако Model View Presenter обикновено се използва в MVC, View работи само с Presenter, това е връзката между модела и изгледа контролира логическите процеси между другите два. Изглед на модел ViewModel MVP с обвързване на команди и данни
Отворени точки Разпределение на логиката между контролер и модел? Уреждане на форматирането и интернационализацията? Място за проверка на въведеното от потребителя? Решават се по различен начин в различни изпълнения/рамки.
Изглед на модел Преглед на данни за обвързване на данни/Изглед на модел
Околна среда/предназначение Аналогично на MVC модел Разделяне на представяне и логика Опростяване на интерфейса чрез свързване на данни
Разделяне на свойства на отделни части Изгледът капсулира структурата на потребителския интерфейс (напр. HTML5). ViewModel капсулира презентационната логика. Моделът капсулира бизнес логиката и нейните данни. View взаимодейства с хлабавото свързване на ViewModel посредством свързване на данни и събития
Изглед Показва данните/информацията (презентация) Получава действия на потребителя. ViewModel не познава ли модела. Не носи отговорност за обработката на потребителски данни. Определя обвързването на данните и командите към ViewModel. В идеалния случай той не съдържа никаква бизнес логика.
Модел Съдържа данни и бизнес логика. Достъп до бекенда, ако е необходимо. Независимо от представянето (View) и контрола (ViewModel). Отговаря за данни и методи за манипулиране на данни (CRUD операции).
ViewModel Предоставя данните от модела и командите за изгледа (един). Прилага логиката на действие на изгледа. Познава модела, но не и изгледа (само чрез свързване на данни). Абонирайте се за модела като наблюдател. Известява се за промени в модела.
Пример: Ъглов източник: https://angular.io/guide/architecture
Пример: Ъглов (View и ViewModel) изглед:
списък с герои
изберете герой от списъка
Предимства По-опростен изглед (почти няма GlueCode) Лесно заменяема Строго разделяне на дизайна и логиката Добра тестваемост Обвързан с данни Преглед се актуализира автоматично Недостатъци По-голяма сложност Двустранен наблюдател Високи изчислителни усилия
Приложението MVVM се използва в XAML/WPF JavaFX HTML5 (HTML/JavaScript, напр. Angular, Knockout.).
Многостепенна и многослойна архитектура
Околна среда Multitier архитектура е архитектурен модел, при който приложението е разделено на няколко независими слоя (нива), които са отделни екземпляри по време на изпълнение. Структурният архитектурен модел на слоеве също разделя приложението на няколко слоя, които обаче обикновено не са всички независими и отделни екземпляри по време на изпълнение. И в двата случая обаждането винаги идва от „по-високия“ към „долния“ слой/ниво. Моделът е модел на OSI слой (теория на операционната система).
Категория/предназначение на слоестата архитектура Слоестата архитектура е често използван принцип на структуриране. Слоестата архитектура намалява сложността на зависимостите в системата. Ясно разделение на задачите. Ниско свързване. Слоевете предотвратяват цикли в графиката на зависимостите.
Категория/предназначение на многостепенната архитектура Разделянето на приложението на няколко изпълнителни единици с ясно дефинирани задачи позволява приложението да се мащабира според изискванията. Всеки слой има своя ясна задача: Ясно разделяне на задачите Архитектура на три нива с ниско свързване: Разделяне на приложението на: Клиент (напр. Клиент на JavaScript, работи в браузъра на потребителя) Сървър (бизнес логика, работи на сървър X или в облака) База данни (постоянство, работи на сървър Y или в облака) Многостепенната архитектура изисква използването на слоеве, но не и обратното.
Примерна слоеста архитектура Източник: FDJP референтна архитектура на софтуера
Пример за многоетажна архитектура Източник: https://www.lucidchart.com/pages/uml/deployment-diagram
Предимства на многостепенната/слоеста архитектура Многостепенните архитектури са лесно мащабируеми и имат висока степен на гъвкавост. Отделни нива респ. Слоевете са лесно взаимозаменяеми. Ако интерфейсите/интерфейсите се променят, само двата съседни нива съответно. Засегнати слоеве. Многостепенните архитектури капсулират машинните зависимости и следователно са лесно преносими. Многостепенните архитектури позволяват локално разпределение на нивата (висока наличност, управление на риска от бедствия)
Мащабируемост Мащабирането обикновено е възможно само със скъп хардуер Многостепенната архитектура обикновено е предпоставка за мащабиране В облака, мащабирането е стандартният облак, който може да се мащабира динамично въз основа на натоварването Многостепенност и следователно многослойната архитектура е стандарт за предприятието днес Приложения.
Недостатъци Често е трудно системите да се структурират добре на слоеве. Между слоевете са необходими допълнителни класове/интерфейси или дори отдалечени интерфейси. Допълнителни режийни разходи поради разделянето на слоеве (препращане на съобщения). Проблеми с производителността (Прекалено) голям брой слоеве причинява ненужно сложна структура
Използването на многопластови и многослойни архитектури е изгодно, когато се изисква висока мащабируемост и гъвкавост на приложението. обменът на отделни слоеве трябва да бъде лесен. Интерфейсите остават стабилни (стандартни интерфейси). Компонентите и хардуерните/софтуерните платформи трябва да бъдат взаимозаменяеми. Хардуерните/софтуерните платформи се купуват в облака. трябва да е възможно допълнително подразделяне на компоненти със сложна функционалност. системата трябва да бъде създадена от няколко екипа с ясни отговорности.