Tarkvaraarenduse eesmärk on luua lahendusi, mis vastavad kasutajate ja ettevõtete vajadustele ja probleemidele. Selle saavutamiseks meeldivad erinevad tehnoloogiad ja arhitektuurimustrid Mudel-vaade-vaademudel (MVVM) ja Model-View-Presenter (MVP) kasutatakse.
Nagu kõigi toodetavate toodete puhul, on esimene samm planeerimise ja kujundamise etapp. Tarkvara kujundamise protsess võib olla eelistatud tehnoloogiliste tööriistakomplektil põhinev spetsifikatsioon ja see võib hõlmata kogu tegevust kontseptsioonist kavandamiseni - rakendamiseni - uuendusteni ja modifikatsioonideni.
See hõlmab valitud arhitektuurimustritel põhinevat madala ja kõrge arhitektuuriprojekti ning kaardistab kujundusmustrite abil korduvkasutatavad lahendused.
Tarkvaraarhitektuur määratleb rakenduse struktuuri, mis vastab tehnilistele, töö- ja kasutajanõuetele, ning viitab sellele, kuidas kood on korraldatud ja hallatud.
Tarkvararakenduse ülesehituse üle otsustamine on kriitilise tähtsusega, kuna see pole juba välja töötatud rakenduse lihtne, muudetav osa; seetõttu tuleb enne programmeerimise alustamist otsustada arhitektuurimustri üle.
Arhitektuurimustrid erinevad mõneti kujundusmustritest, kuna nende ulatus on palju laiem, käsitledes tehnilisemaid probleeme, nagu riistvara jõudlus ja piirangud ning kõrge kättesaadavus. Erinevate arhitektuurimustrite näideteks on MVC, MVVM ja MVP.
Teisest küljest on kujundusmustrid vormistatud parimateks tavadeks, mis hõlbustavad korduvkasutatavat objektorienteeritud arendamist ning mida on lihtsam säilitada ja muuta kui rakenduse arhitektuuri.
Mudelvaate kontroller (MVC) oli üks esimesi veebirakenduste jaoks välja töötatud arhitektuurimustreid, saavutades populaarsuse üheksakümnendate keskpaigast kuni lõpuni, eriti Java-kogukonnas.
Uuemates raamistikes, näiteks Django for Python ja Rails (Ruby on Rails), on suur rõhk kiirel kasutuselevõtul, mistõttu võtab MVC arhitektuurimustrite suure vaatamisväärsusena kasutusele turuosa.
Traditsiooniliselt sisaldas kasutajaliidese arendamine palju koodi keeruka loogika käsitlemiseks, nii et arhitektuurimustrid töötati välja selleks, et vähendada koodi kasutajaliidese (UI) tasemel, muutes selle "puhtamaks" ja paremini hallatavaks.
Nii et koos MVC mustriga koosneb veebirakendus
Mudel haldab andmeid ja äriloogikat ning on olemas ei - sõltuvused Mudel ja Kontroller või Vaade.
Vaade esitab andmed kasutajale toetatud vormingus ja nõutavas paigutuses ning millal Kontroller võtab vastu kasutaja taotlusi (andmete hankimiseks), kutsub ta välja päringu täitmiseks vajalikud ressursid.
Rakendame seda mustrit veebipõhise raamatupoe ehitamisel.
Kasutajad saavad otsida, vaadata, registreerida ja osta raamatuid ning hallata oma profiile ja raamatute loendeid. Kui kasutaja klõpsab kategoorias SCI-FI, peaksid kõik sellega seotud raamatud kuvama kui võimalik.
Kontrollerid käsitlege toiminguid, mis haldavad raamatuid (loetlege, lisage, vaadake jne). Neid võib olla mitu Kontrollerid ühe peamisega Kontroller 'liikluse suunamine'.
Selle näite jaoks on Kontroller kannab nime controller_books.php ja Mudel (nt model_books.php) haldab raamatutega seotud andmeid ja loogikat.
Lõpuks erinevad Vaated nagu näiteks raamatute lisamisel veebikärule või raamatute üksikasjade vaatamisel piltide ja arvustustega, on see kohustuslik.
töötleja_raamatud.php võtab toimingu (kasutaja taotlus) vastu peamiselt Kontroller (nt. indeks.php). töötleja_raamatud.php analüüsib taotlust ja helistab mudel_raamatud.php (andmed), et naasta SCI-FI raamatute loendisse.
Vastutus Mudel on selle teabe esitamine mis tahes rakendatud loogika abil (otsingufiltrite abil). Kontroller võtab seejärel teabe ja edastab selle asjakohasele Vaade (otsinguvaade, prindivaade, detailivaade jne) ja teave esitatakse ( Vaade) kasutajale, kes päringu algatas.
See on MVC mustri põhialus, millest on välja kujunenud arhitektuurimustrite kudevad variatsioonid, näiteks mudel-vaade-esitleja (MVP), mudel-vaade-vaademudel (MVVM), hierarhiline-mudel-vaade-kontroller (HMVC), ja mudeli-vaate-adapter (MVA) jne.
MVP muster
MVP muster on juba mõnda aega tegutsenud ja on MVC variant. See oli mõeldud spetsiaalselt testimise automatiseerimiseks, kus eesmärk oli suurendada automatiseerimise abil testitavate koodide hulka ja muster lahendab mõned esitluskihi probleemid, eraldades äriloogika UI-st.
Ekraan on vaade, kuvatavad andmed on mudel ja saatejuht ühendab need kaks.
MVP koosneb järgmistest komponentidest, millel on eraldi vastutus:
Vaade (veebileht) kuvab ja haldab lehe juhtelemente, edastades sündmused (kasutaja taotlused) Saatejuht mis algatati Vaade.
Saatejuht reageerib nendele sündmustele, lugedes ja värskendades Mudel muuta Vaade ja seetõttu Saatejuhid vastutus on siduda Mudel ja Vaade.
Pärast vaatamist MVC ja MVP mustrite puhul on ühisel mõlemal eraldi vastutusala iga komponendi osas ja need soodustavad üksuste eraldamist Vaade (UI) ja Mudel (andmed). Nende mustrite olulised erinevused ilmnevad rohkem mustrite rakendamisel.
MVP võib olla keerukas lahendus keerukate lahenduste rakendamiseks, kuid kindlasti on sellel suurepäraseid eeliseid, kui seda rakendatakse läbimõeldud lahendusena, ehkki see ei pruugi tingimata olla sobiv lahendus lihtsate lahenduste jaoks.
MVVM muster
MVVM muster oli spetsiaalselt loodud Windowsi esitlusfondi (WPF) ja Microsoft Silverlighti platvormidele ning seda saab kasutada kõigil XAML [i] platvormid.
WPF on Microsofti süsteem, mis loob kasutajaliidesed Windowsi põhistes programmides ja see ilmus esmakordselt .NET Framework 3.0.
MVVM täpsustati alates MVC ja selles mustris Vaade on aktiivne käitumise, sündmuste ja andmete sidumisega ning Vaade sünkroonib Vaatemudel (mis võimaldab esitluse eraldada ja paljastab meetodid ja käsud juhtimiseks ja manipuleerimiseks Mudel.
MVVM koosneb kolmest põhikomponendist:
Vaade võtab vastu andmeid Vaatemudel (andmete sidumise ja meetodite kaudu) ja käitustasemel Vaade muutub, kui reageeritakse sündmustele Vaatemudel.
Vaatemudel vahendab Vaade ja Mudel ja tegeleb Vaade loogika. See suhtleb Mudel - andmete võtmine andmebaasist Mudel ja esitledes seda Vaade kuvamiseks.
Need komponendid on üksteisest lahti ühendatud, mis võimaldab suuremat paindlikkust iseseisvalt töötada, eraldada üksuste testimine ja vahetada need välja, ilma et see mõjutaks ühtegi muud komponenti.
See struktuur võimaldab Mudel ja muud komponendid arenevad iseseisvalt, võimaldades arendajatel töötada samaaegselt välja lahenduse erinevad aspektid. Näiteks kus disainerid töötavad Vaade, nad lihtsalt genereerivad andmeproove, ilma et oleks vaja juurdepääsu muudele komponentidele. See hõlbustab kasutajaliidese lihtsat ümberkujundamist Vaade on rakendatud XAML-is.
Nagu varem mainitud koos MVP, lihtsate lahenduste jaoks poleks vaja arhitektuuri ja kujundusmustrit, nagu näiteks “Tere maailm!” on mis tahes mustri järgimiseks liiga põhiline; kuna aga võetakse kasutusele rohkem funktsioone, funktsioone ja komponente, suureneb rakenduse keerukus ja ka hallatava koodi hulk.
Alates kasutajaliidese väljatöötamise algusest on kujundusmustrid muutumas üha populaarsemaks, et muuta arendusprotsess lihtsamaks, rakendused skaleeritavamaks ja see hõlbustab testimist.
Illustreeritud erinevus MVP ja MVVM mustrite vahel: