МВЦ архитектура

С Википедије, слободне енциклопедије
Дијаграм интеракције између компоненти пројектног узорка МВЦ модел - приказ - контролор

МВЦ (енгл. Model-view-controller) архитектура је пројектни узорак (енгл. pattern) који се обично користи за развој корисиничких интерфејса. Почива на идеји о поновној употреби већ постојећег софтверског кода, олакшавању развоја и каснијем одржавању апликационог софтвера методом раздвајања на посебне компоненте: модел, приказ података (поглед) и контролор (управљач), при чему је компонента за приказ информација одвојена од интеракције корисника са тим информацијама.

Историја[уреди | уреди извор]

МВЦ архитектура се састоји од одређених компоненти у којима је свака задужена за обављање специфичних функција. Такво решење је много боље у односу на раније решења у којима се све налазило на једном месту, што је доводило до отежаног читања изворног кода, отежаног проналажења и исправљања грешака, као и до знатно мање функционалности и флексибилности.[1] МВЦ ја као оквир софтверске архитектуре настао пре него што је измишљен веб-прегледач, и у почетку је коришћен само за креирање графичког корисничког окружења.

Норвешки информатичар Тригви Риенску (норв. Trygve Reenskaug) је током посете Зироксу седамдесетих година први пут представио МВЦ архитектуру примењену на Смаллталк-76.[2][3] Он је МВЦ као апстрактни приказ архитектуре софтвера дефинисао на следећи начин:

  • Модел представља податке. Подаци могу бити само један објекат или структура објеката. Веза између модела и онога што види корисник требала би да буде 1 на 1. Комуникација између модела и спољашњег света би требао да се обавља уз помоћ контролора.
  • Поглед или визуална презентација модела, је повезана са моделом или једним његовим делом. Понаша се као филтер, који из модела наглашава одређене вредности који описују податке (атрибути), док неке друге потискује и тако филтриране податке приказује кориснику. Такође, има могућност ажурирања модела, слањем одговарајућих захтева корисника.
  • Контролор је веза између корисника и података. Он кориснику, у зависности од његовог захтева приказује податке.

Затим су осамдесетих година Џејмс Алтоф (нем. James Althoff) и други употребили верзију МВЦ-а за Смаллталк-80 библиотеку класа. Тек у чланку из 1988-е МВЦ је представљен као посебан појам.[4]

У почетку МВЦ шаблон није функционисао као данас, већ је изгледао овако[5]:

  • модел је податак који апликација приказује
  • приказ података из модела, при чему један податак може више начина приказивања. На пример, очитање температуре се може приказати висином ступца или ознаком за температуру
  • контролор прикупља акције које корисник направи и на основу њих мења модел. Тако на пример, контролор може да прикупља акције које корисник направи мишем, а затим, на основу њих може да измени модел. У том смислу, контролор је представљен као програм који ради с улазним подацима, слично као што се у корисничком окружењу ради са излазним подацима.

На тај начин, приказ података се ажурира директно, на основу измена у моделу. Када се модел измени, он покрене акцију која мења приказ података, при чему контролор не управља приказом података, већ само мења модел, а приказ података се ажурира тек након промена реализованих у моделу.[5]

Компоненте[уреди | уреди извор]

Основна предност МВЦ архитектуре је што се раздвајањем у посебне целине, код великих пројеката, на коме може да ради више особа, омогућава лака измена неког елемента, без велике интервенције у другим елементима, као и поновно коришћење већ направљених елемената.[6]

МВЦ пројектни шаблон се састоји од три засебне, али међусобно повезане компоненте:

  • модел — је централни део апликације, која обухвата променљиву (динамичку) структуру података, директно управљање подацима, логиком и правилима апликације
  • приказ, поглед или преглед података (енгл. view) - било који излазни приказ података у корисничком окружењу (на пример графички помоћу дијаграма), при чему се исти подаци могу приказати на више начина (на пример стубични дијаграми за менаџмент и табеларни приказ за рачуноводство)
  • управљач или контролор (енгл. controller) — улазне податке претвара у команде које управљају моделом или приказом података у корисничком окружењу.

Практично, у оваквој архитектури, модел представља „тело”, приказ података су „очи”, а конотролор „мозак” пројекта.[6]

Модел[уреди | уреди извор]

Модел садржи главне програмске податке, као што су информација о објектима из базе података, састоји се од скупа класа које моделирају и подржавају решавање проблема којим се апликација бави. Обично је стабилна компонента, која траје колико и сам проблем. Сва пословна логика апликације садржана је у моделу.[7] Постоји неколико начина конструкције костура модела. Наиме, програмер може најпре да конструише модел, дефинисањем класа и атрибута унутар класа, те касније, на основу класа да формира базу података.[7]

Чешћи начин је пројектовање најпре базе података, на основу којег се касније генеришу класе. У сваком случају, потребно је узети у обзир и везе између модела у апликацији.[7]

У МВЦ архитектури постоје модел подручја или домена (енгл. Domain model), и модел апликације (енгл. Application model). Модел подручја садржи главне податке о структури података, док модел апликације садржи све потребне функције за управљање тим подацима, односно за упис, измену и брисање података. [7] Зависно од потреба, разликују се три врсте модела: концептуални, логички и физички модел. Концептуални модел садржи само приказ назива ентитета. Логички модел садржи и називе атрибута, примарних и секундарних кључева. Физички модел садржи информацију о томе како се подаци „виде“ у меморији.[7]

Сви подаци се могу добити преко модела, али се модел не може директно позвати, већ се то врши преко контролора, у облику захтева. Ове захтев модел затим обрађује, те враћа контролору захтеване податке. Контролор даље приказује добијене податке крајњем кориснику.[7]

Модел представља једну или више класа са својим стањима, која се могу приказати на захтев корисничког окружења, а контролор их може и мењати.[7]

Разликују се активни модел у коме се стање мења посредством контролора и пасивни модел, код кога се стање у моделу врши без учешћа контролора. Међутим, у пракси је чешћи сценарио у којем модел има активну улогу и представља део пословне логике. У том случају, модел обезбеђује методе које ће се користити да би се ажурирало тренутно стање објеката. Модел такође може обавестити корисничко сучеље о промени стања, при чему се приказ тренутно освежава.[7]

У основном облику модел нема никакво сазнање о приказу података и контролору, док у проширеној верзији МВЦ архитектуре, модел може да садржи и основне операције за рад са приказима, код такозваног „посматрачког” пројектног узорка (енгл. Observer pattern).

Приказ података[уреди | уреди извор]

Компонента за приказ података је последњи слој МВЦ архитектуре, који садржи окружење апликације, односно обезбеђује различите начине за презентовање података добијених од модела, преко контролора.

Корисник може видети само оно што се види у овој компоненти, док су модел и контролор обично скривени од корисника.

Најважнија особина ове компоненте је њена једноставност, јер представља визуелни приказ модела који садржи методе за приказивање и омогућава кориснику да мења податке. Она свакако не треба да буде надлежна за складиштење података, осим када се користи кеширање као механизам за побољшање карактеристика.

Његов задатак је што јасније приказивање података који занимају корисника те до тих података корисник треба доћи што једноставнијим путем. Структура прегледа не сме бити превише комплексна и нити имати превелику одговорност. Најбољи прикази података су они који одговарају само за један модел, те приказују податке само тог модела.[8] Могућ је приказ једног или више објеката из модела, при чему се не бави обрадом података. Приказ података зависи од модела, односно метода модела преко којих се подаци добијају. Приказ мора што јасније приказивати податке који занимају корисника те до тих података корисник треба доћи што једноставнијим путем.[8] Визуална репрезентација података може се налазити у различитим форматима, као што су веб-прегледач, или датотеке у ХТМЛ, XМЛ или ПДФ формату.

Контролор[уреди | уреди извор]

Контролор представља посредника између приказа података и модела. Садржи главне механизме за контролу тока програма, односно понашање саме апликације и управља корисничким захтевима.[7] Он је програмски најзахтевнији део апликације.[8]

Контролор интерпретира улазне податке корисника и прослеђује их до модела или их приказује кориснику. Он садржи део апликацијске логике и има способност да утиче на стање модела, односно одлучује како модел треба да се измени, као резултат корисничких захтева, као и начин на који ће се подаци приказати.[7]

Интеракције између компоненти[уреди | уреди извор]

Осим поделе апликације у три одвојене компоненте, МВЦ архитектура омогућава и интеракцију између њих:

  • приказ (енгл. view) - приказује кориснику стање модела, обезбеђује корисничко сучеље, помоћу кога корисник уноси податке и позива одговарајуће операције које треба да се изврше над подацима
  • контролор (енгл. controller) - ослушкује и прихвата захтеве клијента за извршење неке операције. Након тога позива операцију која је дефинисана у моделу, и уколико модел промени стање, приказује га кориснику.
  • модел - представља стање система које се може променити извршавањем операција над објектима у моделу података. За модел није битно како се управља подацима, нити начин на који се подаци приказују кориснику.

Важно је запамтити да приказ у корисничком окружењу и конотролор зависе од модела, док модел не зависи нити од приказа, нити од контролора компоненти, што омогућава развој и тестирање модела независно од његове презентацијске логике.[9]

Предности и мане[уреди | уреди извор]

Предности МВЦ архитектуре[10]:

  • модел се може приказати на више начина
  • лакше је додати нови приказ података (на пример нову интернет страницу која приказује постојеће податке или део њих)
  • лакша се мења интеракција са корисником
  • више програмера може радити истовремено и паралелно на различитим компонентама
  • могућност поновна коришћења кода
  • појединачни делови се могу лако тестирати, мењати и побољшавати
  • приказ података је одвојен од логике обраде података

Мане МВЦ архитектуре су[10]:

  • превише комплексна за примену код развоја мањих апликација, што доводи до погоршања како њеног дизајна, тако и њених карактеристика
  • услед честих измена модела приказ података може остати преплављен захтевима за измену, што може довести до кашњења у одговорима на захтеве.

Примена МВЦ архитектуре у wеб апликацијама[уреди | уреди извор]

МВЦ је широко прихваћен као пројектни узорак за апликације на светској мрежи, у свим значајнијим програмским језицима. Неколико комерцијалних и некомерцијалних програмских оквира (енгл. framework) користе овај пројектни узорак. Сваки од њих варира у интерпретацији начина на који су подељене одговорности између клијента и сервера. Код оних ранијих, цео модел, приказ и конотролор су се налази на серверу. Клијент је само слао захтев (на пример преко формулара), а потом примао комплетну новоформирану веб-страницу.

У веб-апликацијама компонента за приказ (поглед) садржи: ХТМЛ, ЦСС, Јаваскрипт, XМЛ или ЈСОН и друге, при чему се прва три не препоручују у контролору. У веб-апликацијама контролор представља први слој који се позива када веб-претраживач позове неку веб-адресу.

Напредак технологије је омогућио да се МВЦ компоненте делом извршавају код клијента (Ајаx).

Унапређивање МВЦ архитектуре[уреди | уреди извор]

МВЦ архитектура се већ неко време бави унапређивањем претходних верзија, па је развијено више различитих верзија МВЦ архитектуре. Све оне су углавном сличне, с мањим разликама у логици одвијања процеса и називима компоненти.[11]

У модерним апликацијама од 2000-те године, контролор је програм или део компјутерског кода који служи за комуникацију између модела и корисничког окружења, директним позивањем или помоћу посматрача (енгл. observer). С обзиром да делови класичног МВЦ-а немају смисла код „дебелих” клијената, и аспекти МВЦ архитектуре су такође еволуирали, али само као варијанте оригиналног појма, као што су ХМВЦ (енгл. Hierarchical model–view–controller), МВА (енгл. Model-View-Adapter), МВП (енгл. Model-View-Presenter arhitektura), МВВМ (енгл. Model-View-ViewModel), код којих је МВЦ архитектура прилагођена на другачије начине.

МВА[уреди | уреди извор]

МВА архитектура се све више користи у веб-технологији, нарочито на страни апликације клијента (на пример у Јаваскрипту) постоји посебна компонента - адаптер која се налази између компоненти модела и приказа податка, која регулише процесе тако што прати рад и процесе, на основу одговора које добија од околних компоненти. На пример, када компонента за презентацију шаље „сигнал“ да је у текстуално поље у формулару уписано име, адаптер прима ту информацију и шаље захтев моделу да ажурира податак, који ће се касније спремити у бази података. Могућ је и обрнут процес. Уколико се подаци у моделу промене, модел ће послати сигнал адаптеру који ће реаговати у компоненти за презентацију кориснику, тако што ће ажурирати садржај формулара.[11]

МВП[уреди | уреди извор]

МВП архитектура

МВП архитектура је најзаступљенија код обрасца у Андроиду. Модел је од корисника најудаљенији и састоји се од спољашњих ентитета који комуницирају с базом података или врше мржно повезивање. У моделу се обавља претварање података из једног у други тип, како би се обезбедили чисти подаци у корисничком сучељу. Слој у коме се приказују подаци, односно слој платформе је најдужи део МВП шаблона. Служи искључиво за приказ сучеља и података у њему, као и послове везане за корисничку интеракцију са слојем презентације. Док овај слој зависи од платформе, остали слојеви се могу без проблема поново искористити у неким другим пројектима или деловима апликације. Након корисничке интеракције, слој презентације прима поруку о истој. Након испитивања захтева, из слоја презентације у моделу се покреће захтевана акција (као на пример регистрацију корисника), а при чијем се завршетку, са новим подацима презентација обавештава и одатле приказују кориснику. Свака акција коју предузима корисник мора да буде прослеђена слоју презентације, који одлучује о томе на који начин ће приказ кориснику даље наставити с радом. Овакав шаблон у коме постоји слој презентације који стриктно говори слоју у коме се приказују подаци како ће се подаци приказати или шта ће се наредно догодити, је незгодан због тога што изискује исписивање веома дугачког програмског кода који се понавља, јер је за сваки тип податка потребно исписати посебну функцију.[12]

МПМВ[уреди | уреди извор]

МВВМП архитектура

МПМВ архитектура је развијена упоредо са МВП архитектуром. Њена структура је врло слична, с том разликом што се уместо слоја за презентацију, користи повезивање података (енгл. Data Binding — DB) и групни подаци за свако стање приказа података (енгл. View State — VS), који се везује за слој у коме се приказују подаци, преко модела приказа (енгл. View State — VS). На крају сваког циклуса, само се мења стање приказа, тако да слој у коме се приказују подаци аутоматски добије поруку да треба да се ажурира, односно није потребно слати захтеве, пошто слој за приказивање реагује на промене и аутоматски их бележи. Међутим, пошто је МВВМ архитектуру тешко применити, посебно код веб-прегледача. Једно решење је употреба додатног слоја веб-прегледача, којег представљају мрежни усмеривачи (енгл. router). Друго решење је коришћење комбинације МВП и МВВМ приступа, гдје се МВП приступ брине о порукама и веб-прегледачу, а МВВМ део се брине о току података кроз циклус и о ажурирању слоја приказа података.[12]

ХМВЦ[уреди | уреди извор]

Структурна шема апликације по ХМВЦ архитектури

ХМВЦ архитектура је доста сложенија структура, у којој се једна већа апликација раздваја на мање, такозвне модуле, од којих сваки има сопствену унутрутрашњу структуру израђену према МВЦ архитектури. Најбољи пример коришћења ХМВЦ архитектуре су системи за динамичко управљање садржаја (ЦМС) на мрежним страницама. Код њих се поједине функционалности, као што су могућност писања чланака или коментара раздвојени у модуле, који функционишу засебно, али тако да корисник не примећује да се страница која се приказује помоћу веб-прегледача састоји од мањих делова.[13]

Види још[уреди | уреди извор]

Извори[уреди | уреди извор]

  1. ^ Смијуљ & Мештровић 2014, стр. 217.
  2. ^ Нотес анд Хисторицал доцументс фром Трyгве Реенскауг, инвентор оф МВЦ.
  3. ^ "А ноте он ДyнаБоок реqуирементс", Трyгве Реенскауг, 22 Марцх 1979, СyсРеq.пдф.
  4. ^ Краснер, Гленн Е.; Степхен Т. Попе (1988). „А цоокбоок фор усинг тхе модел-виеw цонтроллер усер интерфаце парадигм ин Смаллталк-80”. Тхе ЈОТ. СИГС Публицатионс.  Алсо публисхед ас "А Десцриптион оф тхе Модел-Виеw-Цонтроллер Усер Интерфаце Парадигм ин тхе Смаллталк-80 Сyстем" (Репорт), ПарцПлаце Сyстемс; Ретриевед 2012-06-05.
  5. ^ а б Папратовић 2016, стр. 3.
  6. ^ а б Маркуш Митриновић 2016, стр. 14.
  7. ^ а б в г д ђ е ж з и Маркуш Митриновић 2016, стр. 17.
  8. ^ а б в Бистровић 2018, стр. 8.
  9. ^ Маркуш Митриновић 2016, стр. 16.
  10. ^ а б Маркуш Митриновић 2016, стр. 19.
  11. ^ а б Смијуљ & Мештровић 2014, стр. 218.
  12. ^ а б Бабић 2018.
  13. ^ Папратовић 2016, стр. 2.

Литература[уреди | уреди извор]

Преузето из „https://sr.wikipedia.org/w/index.php?title=MVC_arhitektura&oldid=26760137”