Namen razvoja programske opreme je ustvariti rešitve, ki bodo reševale potrebe in težave uporabnikov in podjetij. Da bi to dosegli, imajo različne tehnologije in arhitekturne vzorce Model-View-ViewModel (MVVM) in Predstavitev modela-predstavitev (MVP) so uporabljeni.
Kot pri vsem, kar se izdeluje, je prvi korak načrtovanje in načrtovanje. Proces oblikovanja programske opreme je lahko specifikacija, ki temelji na najprimernejšem naboru tehnoloških orodij in lahko vključuje vse dejavnosti od zasnove - do - načrtovanja - do - izvajanja - do posodobitev in sprememb.
Zajema arhitekturno zasnovo nizkega in visokega nivoja, ki temelji na izbranih vzorcih arhitekture, in oblikuje rešitve za večkratno uporabo z uporabo oblikovalskih vzorcev.
Programska arhitektura definira strukturo aplikacije, ki ustreza tehničnim, operativnim in uporabniškim zahtevam ter se nanaša na način organizacije in upravljanja kode.
Odločitev za arhitekturo programske opreme je ključnega pomena, saj ni že lahk, spremenljiv del aplikacije, ki je že razvit; zato je treba določiti arhitekturni vzorec pred začetkom programiranja.
Arhitekturni vzorci se nekoliko razlikujejo od vzorcev oblikovanja, saj je njihov obseg veliko širši, saj obravnava več tehničnih vprašanj, kot so zmogljivost in omejitve strojne opreme ter velika razpoložljivost. Primeri različnih vzorcev arhitekture so MVC, MVVM in MVP.
Po drugi strani pa so vzorci oblikovanja formalizirane najboljše prakse, ki olajšajo objektno orientiran razvoj za večkratno uporabo in jih je lažje vzdrževati in spreminjati kot arhitektura aplikacije.
Model Model Controller (MVC) je bil eden prvih arhitekturnih vzorcev, razvitih za spletne aplikacije, ki je pridobil na popularnosti od sredine do konca devetdesetih let, zlasti pri skupnosti Java.
Novejši okviri, kot sta Django za Python in Rails (Ruby on Rails), se močno osredotočajo na hitro uvajanje, zato MVC prevzema tržni delež kot veliko privlačnost arhitekturnih vzorcev.
Tradicionalno je razvoj uporabniškega vmesnika vseboval veliko kode za obravnavo zapletene logike, zato so bili vzorci arhitekture zasnovani tako, da zmanjšajo kodo na ravni uporabniškega vmesnika (uporabniški vmesnik), zaradi česar je bolj "čist" in obvladljiv.
Torej, z vzorcem MVC je sestavljena spletna aplikacija
The Model obdeluje podatke in poslovno logiko in obstajajo št odvisnosti med Model in Krmilnik ali Pogled.
The Pogled uporabniku predstavi podatke v podprti obliki in zahtevani postavitvi ter kdaj Krmilnik prejme uporabniške zahteve (za pridobitev podatkov), pokliče ustrezne vire, potrebne za dokončanje zahteve.
Uporabimo ta vzorec pri gradnji spletne trgovine s knjigami.
Uporabniki lahko iščejo, si ogledujejo, registrirajo in kupujejo knjige ter upravljajo svoje profile in sezname knjig. Ko uporabnik klikne na kategorijo SCI-FI, bi morale biti vse povezane knjige prikazane kot na voljo.
The Krmilniki ravnajte z dejanji, ki upravljajo knjige (seznam, dodajanje, ogled itd.) Lahko jih je več Krmilniki z eno glavno Krmilnik "usmerjanje prometa".
Za ta primer je Krmilnik se imenuje controller_books.php in Model (npr. model_books.php) obdeluje podatke in logiko, povezano s knjigami.
Nazadnje drugače Pogledi bo potrebno, npr. pri dodajanju knjig v spletno košarico ali pri ogledu podrobnosti knjige s slikami in ocenami.
The controller_books.php prejme dejanje (zahtevo uporabnika) od glavnega Krmilnik (npr. index.php). The controller_books.php analizira zahtevo in pokliče model_books.php (podatki) za vrnitev seznama SCI-FI knjig.
Odgovornost Model je posredovanje teh informacij z uporabo katere koli uporabljene logike (z uporabo iskalnih filtrov). The Krmilnik nato informacije vzame in posreduje ustreznim Pogled (iskalni pogled, pogled tiskanja, prikaz podrobnosti itd.) in informacije so predstavljene (prek Pogled) uporabniku, ki je sprožil zahtevo.
To je osnova vzorca MVC, ki se je razvil neenakosti različic arhitekturnih vzorcev, kot so Model-View-Presenter (MVP), Model-View-ViewModel (MVVM), Hierarchical-Model-View-Controller (HMVC), in Model-View-Adapter (MVA) itd.
Vzorec MVP
The Vzorec MVP je že nekaj časa in je različica MVC. Zasnovan je bil posebej za testno avtomatizacijo, kjer je bil cilj povečati količino kode, ki jo je mogoče preizkusiti z avtomatizacijo, vzorec pa obravnava nekatere težave s predstavitvenim slojem, izolira poslovno logiko od uporabniškega vmesnika.
Zaslon je Pogled, podatki, ki jih prikazuje, je Model, predstavitelj pa dva skupaj.
MVP obsega naslednje sestavne dele z ločenimi odgovornostmi:
The Pogled (spletna stran) prikaže in upravlja krmiljenje strani s posredovanjem dogodkov (uporabniških zahtev) na Voditelj ki so bili začeti v Pogled.
The Voditelj se na te dogodke odzove z branjem in posodabljanjem Model spremeniti Pogled in zato Predstavitve odgovornost je, da vežejo Model in Pogled.
Po ogledu MVC in MVP V splošnem imata obe skupni odgovornosti za vsako komponento in spodbujata ločitev med EU Pogled (Uporabniški vmesnik) in Model (podatki). Pomembne razlike med temi vzorci so bolj vidne v načinu izvajanja vzorcev.
MVP utegne biti zapleten vzorec za napredne rešitve, vsekakor pa ima velike koristi, če se izvaja kot dobro zasnovana rešitev, čeprav morda ni nujno ustrezna izbira za preproste rešitve.
Vzorec MVVM
The MVVM vzorec je bil zasnovan posebej za platforme Windows Presentation Foundation (WPF) in Microsoft Silverlight in se lahko uporablja na vseh XAML [i] ploščadi.
WPF je Microsoftov sistem, ki prikazuje uporabniške vmesnike v programih, ki temeljijo na sistemu Windows, in je bil prvič izdan v .NET Framework 3.0.
MVVM je bil rafiniran iz MVC in v tem vzorcu Pogled je aktiven z vedenji, dogodki in vezavo podatkov ter Pogled se sinhronizira z ViewModel (ki omogoča ločitev predstavitve in izpostavlja metode in ukaze za upravljanje in manipuliranje z Model.
MVVM obsega tri osnovne komponente:
The Pogled prejema podatke od ViewModel (prek zavezujočih podatkov in metod) in med izvajanjem Pogled se bo spremenilo, ko se bo odzvalo na dogodke v ViewModel.
The ViewModel posreduje med Pogled in Model in ročaji Pogled logika. Vzajemno deluje z Model - odvzem podatkov iz Model in ga predstavil Pogled prikazati.
Te komponente so ločene med seboj, kar omogoča večjo fleksibilnost za samostojno delo, izoliranje preskušanja enot in njihovo zamenjavo, ne da bi to vplivalo na nobeno drugo komponento.
Ta struktura omogoča Model in druge komponente se razvijajo neodvisno, kar omogoča razvijalcem, da hkrati delajo na različnih vidikih rešitve. Na primer, kjer oblikovalci delajo na Pogled, preprosto generirajo vzorce podatkov, ne da bi potrebovali dostop do drugih komponent. To omogoča enostavno prenovo uporabniškega vmesnika kot Pogled se izvaja v XAML.
Kot smo že omenili s MVP, preproste rešitve ne bi potrebovale arhitekturnih in oblikovalskih vzorcev, kot je "Hello World!" je preveč osnovno, da bi sledili kakršnemu koli vzorcu; vendar, ko se uvaja več funkcij, funkcij in komponent, se kompleksnost aplikacije povečuje in s tem se poveča tudi količina kode, ki jo je treba upravljati.
Od začetka razvoja uporabniškega vmesnika postajajo vzorci oblikovanja vse bolj priljubljeni, da olajšajo razvojni postopek, aplikacije so bolj prilagodljive in omogočajo lažje testiranje.
Ilustrirana razlika med vzorcema MVP in MVVM: