Архитектонска шема
Организација на моделот на архитектура и интеракција помеѓу компонентите
Класификација Постојат широк спектар на архитектонски обрасци кои разумно се користат во зависност од обемот и опкружувањето на проектот: Model-View-Controller, Model-View-ViewModel повеќеслојна и слојна архитектура, дистрибуирани системи, дизајн на домен, веб-шестоаголна архитектура, JavaEE, .Net, клиент -Сервер-услуга-ориентирана (процесно-ориентирана), peer-to-peer. Богат клиент, 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 Ги прикажува податоците/информациите (презентација) Пренесува кориснички влез во контролорот Го знае контролорот и моделот Дали е информиран за промените на податоците од моделот (набverудувач)
Контролорот управува со еден или евентуално неколку прегледи. Прима кориснички дејства (настани) од приказот и ги проценува. Ги препраќа дејствата кон моделот.Моделот може да биде информиран за промените на податоците (набудувач) со цел да реагира на промените во статусот. Може да го контролира прегледот (промена на преглед, промена на друга страница)
Модел Функционален дел од апликацијата. Одговорен за управување со податоци и деловна логика. Набervудуван Ги знае регистрираните набудувачи (прегледи и контролори). Ги известува сите набversудувачи за промените на податоците или статусот
MVC со набудувач/набудувач
Ракување со настани во моделот MVC
Упатување на други обрасци Набerудувач Ако презентерот за моделски приказ обично се користи во MVC, View само дејствува со презентер, ова е врската помеѓу моделот и прегледот ги контролира логичките процеси помеѓу другите два. Model View ViewModel MVP со врзување за команди и податоци
Отворени точки Распределба на логиката помеѓу контролорот и моделот? Решавање на форматирање и интернационализација? Место за валидација на влезот на корисникот? Се решаваат различно во различни имплементации/рамки.
Врски за врзување на податоци/Презентер за преглед на модел Преглед на модел
Environmentивотна средина/цел аналогно на моделот MVC Поделување на репрезентацијата и логика Поедноставување на интерфејсот преку врзување на податоци
Карактеристики Разделување во посебни делови Погледот ја инкапсулира структурата на UI (на пример, HTML5). ViewModel ја инкапсулира логиката на презентацијата. Моделот ги содржи деловната логика и нејзините податоци. Прегледот комуницира со лабавата спојка ViewModel со помош на врзување на податоци и настани
View Ги прикажува податоците/информациите (презентација) Прима активности на корисникот. Дали ViewModel не го познава моделот. Не е одговорен за обработка на кориснички податоци. Ги дефинира обврзувачките податоци и команди за ViewModel. Идеално, не содржи никаква деловна логика.
Модел Содржи податоци и деловна логика. Пристапи до задниот дел ако е потребно. Независно од презентација (View) и контрола (ViewModel). Одговорен за податоци и методи за манипулација со податоци (CRUD операции).
ViewModel Ги обезбедува податоците од моделот и командите за (еден) приказ. Ја спроведува акционата логика на погледот. Го познава моделот, но не и прегледот (само преку врзување на податоци). Претплатете се на моделот како набудувач. Дали е известен за промените во моделот.
Пример: Аголен извор: https://angular.io/guide/architecture
Пример: Преглед на агол (поглед и модел на преглед):
список на херои
изберете херој од списокот
Предности Поедноставен преглед (скоро и да нема GlueCode) Лесно разменливо Строго раздвојување на дизајнот и логиката Добра тестираност со податоци Поврзани податоци Погледнете ги ажурирањата автоматски Недостатоци Поголема сложеност Двостран набудувач Голем напор за компјутер
Апликација MVVM се користи во XAML/WPF JavaFX HTML5 (HTML/JavaScript, на пример, аголен, нокаут.).
Повеќеслојна и слоевита архитектура
Environmentивотна средина Мултилитер архитектура е архитектонска шема во која апликацијата е поделена на неколку независни слоеви (нивоа), кои се посебни инстанци за време на траење. Слојната архитектонска шема исто така ја дели апликацијата во неколку слоеви, кои, сепак, обично не се сите независни и одделни инстанци за време на траење. Во двата случаи, повикот секогаш доаѓа од „повисокиот“ до „понискиот“ слој/ниво. Моделот е модел на слој OSI (теорија на оперативен систем).
Категорија/намена на слоевита архитектура Архитектурата на слоевите е често користена принцип на структурирање. Архитектурата на слоевите ја намалува комплексноста на зависностите во системот Јасна поделба на задачите Ниско спојување Слоевите спречуваат циклуси во графиконот за зависноста Слоевите се добро разбрани.
Категорија/намена на повеќестепената архитектура Поделбата на апликацијата во неколку единици за траење со јасно дефинирани задачи овозможува апликацијата да се зголеми според потребите. Секое ниво има своја јасна задача: Јасна поделба на задачите Ниска спојка 3-ниво на архитектура: Поделба на апликацијата во: Клиент (на пр. Клиент JavaScript, работи во прелистувачот на корисникот) Сервер (деловна логика, работи на сервер X или во облак) База на податоци (упорност, работи на сервер Y или во облак) Повеќеслојна архитектура бара употреба на слоеви, но не и обратно.
Пример слоевит архитектура Извор: референтна архитектура на софтвер FDJP
Пример Извор на архитектура за мултилитер: https://www.lucidchart.com/pages/uml/deployment-diagram
Предности на повеќеслојна/слоевита архитектура Повеќеслојните архитектури се лесно размерливи и имаат висок степен на флексибилност. Индивидуални нивоа Слоевите се лесно заменливи. Ако се променат интерфејсите/интерфејсите, се однесуваат само на двете соседни нивоа. Зафатени слоеви. Повеќестепените архитектури ги капсулираат зависностите од машината и затоа се лесно преносливи. Повеќе нивоа архитектури овозможуваат локална дистрибуција на нивоа (висока достапност, управување со ризик од катастрофи)
Приспособливост Размерувањето обично е можно само со скап хардвер Повеќеслојната архитектура обично е предуслов за обемување во облакот, обемот е стандард што Облакот може динамично да го размери врз основа на оптоварувањето повеќеслојно и затоа слоевата архитектура е стандард за претпријатието денес Апликации.
Недостатоци Честопати е тешко уредно да се структурираат слоеви. Меѓу слоевите се потребни дополнителни класи/интерфејси, па дури и оддалечени интерфејси. Дополнителни надземни трошоци поради раздвојување во слоеви (проследување пораки)
Употребата на повеќеслојни и слоевити архитектури се поволни кога се потребни висока приспособливост и флексибилност на апликацијата. размената на одделни слоеви треба да биде лесна. Интерфејсите остануваат стабилни (стандардни интерфејси). Компонентите и хардверските/софтверските платформи треба да бидат заменливи. Хардверските/софтверските платформи се купуваат во облак. треба да биде можно дополнително да се поделат компонентите со комплексна функционалност. системот треба да биде креиран од неколку тимови со јасни одговорности.