Ero MVVM n ja MVP n välillä

Ohjelmistokehityksen tarkoituksena on rakentaa ratkaisuja, jotka vastaavat käyttäjien ja yritysten tarpeita ja ongelmia. Tämän saavuttamiseksi erilaisia ​​tekniikoita ja arkkitehtuurimalleja kuten Malli-näkymä-näkymämalli (MVVM) ja Malli-näkymä-esittelijä (MVP) käytetään.

Kuten minkä tahansa valmistetun tapauksessa, ensimmäinen askel on suunnittelu- ja suunnitteluvaihe. Ohjelmistosuunnitteluprosessi voi olla määritelmä, joka perustuu ensisijaiseen teknologiatyökalupakettiin, ja se voi kattaa kaiken toiminnan suunnittelusta suunnittelusta toteutukseen toteutukseen päivityksiin ja muutoksiin.

Se kattaa matalan ja korkean tason arkkitehtisuunnittelun, joka perustuu valittuihin arkkitehtuurimalleihin, ja kartoittaa uudelleenkäytettävät ratkaisut suunnittelumallien avulla.

Ohjelmistosovellusrakenne

Ohjelmistoarkkitehtuuri määrittelee sovelluksen rakenteen, joka täyttää tekniset, toiminnalliset ja käyttäjän vaatimukset, ja viittaa koodin organisointiin ja hallintaan.

Ohjelmistosovelluksen arkkitehtuurin valinta on kriittistä, koska se ei ole helppo, muutettavissa oleva osa jo kehitettyä sovellusta; sen vuoksi arkkitehtonisesta kuviosta on päätettävä ennen ohjelmoinnin alkamista.

Arkkitehtuurikuviot ovat jonkin verran erilaisia ​​kuin suunnittelumallit, koska niiden laajuus on paljon laajempi käsittelemällä teknisiä kysymyksiä, kuten laitteiston suorituskyky ja rajoitukset, ja korkea käytettävyys. Esimerkkejä erilaisista arkkitehtuurimalleista ovat MVC, MVVM ja MVP.

Toisaalta suunnittelumallit ovat virallistettuja parhaita käytäntöjä, jotka helpottavat uudelleenkäytettävää oliokeskeistä kehittämistä ja joita on helpompi ylläpitää ja muuttaa kuin sovelluksen arkkitehtuuria. 

Arkkitehtuurikuviot

Mallinäkymän ohjain (MVC) oli yksi ensimmäisistä arkkitehtuurimalleista, jotka kehitettiin verkkosovelluksia varten, ja se sai suosion 1990-luvun puolivälistä myöhään etenkin Java-yhteisössä.

Uudemmissa kehyksissä, kuten Django Pythonille ja Rails (Ruby on Rails), keskitytään voimakkaasti nopeaan käyttöönottoon, minkä vuoksi MVC ottaa markkinaosuutensa arkkitehtonisten kuvioiden suurimmaksi vetovoimaksi.

Perinteisesti käyttöliittymäkehitys sisälsi paljon koodia monimutkaisen logiikan käsittelemiseksi, joten arkkitehtuurimalleja suunniteltiin vähentämään koodia käyttöliittymän (UI) tasolla tekemällä siitä "puhdas" ja hallittavissa.

Joten MVC-mallissa web-sovellus koostuu

  • Malli (Tiedot)
  • näkymä (rajapinta tietojen tarkastelemiseen ja käsittelemiseen)
  • ohjain (tietoihin suoritetut toiminnot ja toimenpiteet)

Malli käsittelee tietoja ja liiketoimintalogiikkaa, ja niitä on ei - riippuvuudet Malli ja ohjain tai näkymä.

näkymä näyttää tiedot käyttäjälle tuetussa muodossa ja vaaditussa asettelussa, ja kun ohjain vastaanottaa käyttäjäpyyntöjä (tietojen hakemiseksi), se kutsuu tarvittavat resurssit, joita tarvitaan pyynnön täyttämiseen.

Käytämme tätä mallia online-kirjakaupan rakentamiseen.

Käyttäjät voivat etsiä, katsella, rekisteröidä ja ostaa kirjoja sekä hallita profiilejaan ja kirjaluetteloitaan. Kun käyttäjä napsauttaa SCI-FI-luokkaa, kaikkien siihen liittyvien kirjojen pitäisi näkyä saatavana.

ohjaimet käsittele kirjoja hallinnoivia toimintoja (luettelo, lisää, katsele jne.). Niitä voi olla useita ohjaimet yhdellä päällä ohjain 'liikenteen ohjaaminen'.

Tässä esimerkissä ohjain on nimeltään controller_books.php ja Malli (esim. model_books.php) käsittelee kirjoihin liittyviä tietoja ja logiikkaa.

Viimeiseksi, erilainen Luettu vaaditaan, kuten lisättäessä kirjoja online-ostoskoriin tai katseltaessa kirjan yksityiskohtia kuvien ja arvostelujen avulla.

controller_books.php vastaanottaa toiminnan (käyttäjän pyynnön) päähenkilöltä ohjain (esim. index.php). controller_books.php analysoi pyynnön ja soittaa model_books.php (tiedot) palauttaaksesi SCI-FI-kirjojen luettelon.

EU: n vastuu Malli on antaa kyseiset tiedot käyttämällä mitä tahansa logiikkaa, jota käytettiin (käyttämällä hakusuodattimia). ohjain ottaa sitten tiedot ja välittää ne asianomaiselle näkymä (hakunäkymä, tulostusnäkymä, yksityiskohtinäkymä jne.) ja tiedot esitetään ( näkymä) käyttäjälle, joka aloitti pyynnön.

Tämä on MVC-mallin perusteet, joka on kehittänyt arkkitehtuurikuvioiden kutevia variaatioita, kuten malli-näkymä-esittelijä (MVP), malli-näkymä-näkymämalli (MVVM), hierarkkinen malli-näkymä-ohjain (HMVC), ja Model-View-Adapter (MVA) jne.

MVP-malli

Malli-näkymä-esittelijä (MVP)

MVP-malli on ollut jonkin aikaa ja on muunnos MVC: stä. Se on suunniteltu erityisesti testiautomaatioon, jossa tavoitteena oli lisätä automatisoinnin avulla testattavan koodin määrää, ja malli korjaa joitain esityskerroksen ongelmia eristäen liiketoimintalogiikan käyttöliittymästä.

Näyttö on näkymä, näytöllä näkyvät tiedot ovat malli, ja Presenter kiinnittää nämä kaksi toisiinsa.

MVP käsittää seuraavat komponentit erillisillä vastuulla:

  • Malli (määrittelee näytettävät tiedot)
  • näkymä (näyttää tiedot mallista ja reitittää käyttäjän pyynnöt Presenterille).
  • Juontaja (vuorovaikutuksessa näkymän ja mallin välillä ja koukuttamalla ne yhteen)

näkymä (verkkosivu) näyttää ja hallitsee sivun ohjaimia lähettämällä tapahtumia (käyttäjäpyyntöjä) Juontaja jotka aloitettiin näkymä.

Juontaja vastaa näihin tapahtumiin lukemalla ja päivittämällä Malli muuttaa näkymä ja siksi esittäjän vastuu on sitoutua Malli ja näkymä.

Tarkasteltuaan MVC ja MVP malleissa, yhteisyys on, että molemmilla on erilliset vastuut kullekin komponentille, ja ne edistävät erottamista toisistaan näkymä (UI) ja Malli (Tiedot). Merkittävät erot näiden kuvioiden välillä ilmenevät paremmin kuvioiden toteuttamisessa.

MVP voi olla monimutkainen malli edistyneiden ratkaisujen toteuttamiseksi, mutta sillä on varmasti suuria etuja, jos se toteutetaan hyvin suunnitelluna ratkaisuna, vaikka se ei välttämättä ole sopiva valinta yksinkertaisille ratkaisuille.

MVVM-malli

Malli-näkymä-näkymämalli (MVVM)

MVVM kuvio on suunniteltu erityisesti Windows Presentation Foundation (WPF) - ja Microsoft Silverlight -ympäristöille, ja sitä voidaan käyttää kaikissa XAML [i] alustat.

WPF on Microsoft-järjestelmä, joka tuottaa käyttöliittymiä Windows-pohjaisissa ohjelmissa, ja se julkaistiin ensin .NET Framework 3.0: ssa.

MVVM tarkennettiin MVC ja tässä kuviossa näkymä on aktiivinen käyttäytymiseen, tapahtumiin ja tietojen sitomiseen liittyvissä asioissa, ja näkymä synkronoi ViewModel (joka mahdollistaa esityksen erottamisen ja paljastaa menetelmät ja komennot hallita ja käsitellä Malli.

MVVM käsittää kolme ydinosaa:

  • Malli (edustaa tietoja validoinnilla ja liiketoimintalogiikalla)
  • näkymä (Näkymä on vastuussa käyttäjän näytöllä näkemän rakenteen, ulkoasun ja ulkonäön määrittelystä. Ihannetapauksessa näkymä määritetään puhtaasti XAML: llä, rajoitetulla kooditakauksella, joka ei sisällä liikelogiikkaa.kaksi tapaa dataa- sitova näkymä ja ViewModel näytönohjaimet, jotka synkronoivat mallin ja ViewModelin näkymän kanssa)
  • ViewModel (erottaa näkymän mallista ja paljastaa menetelmät ja komennot tietojen käsittelemiseksi (malli).

näkymä vastaanottaa tietoja ViewModel (tietojen sitomisen ja menetelmien kautta) ja suorituksen aikana näkymä muuttuu, kun reagoidaan ViewModel.

ViewModel välittää näkymä ja Malli ja käsittelee näkymä logiikka. Se on vuorovaikutuksessa Malli - tietojen ottaminen Malli ja esittämällä sen näkymä näyttää.

Nämä kaikki komponentit on irrotettu toisistaan, mikä antaa suuremman joustavuuden työskennellä niiden kanssa itsenäisesti, eristää yksikkötestaukset ja vaihtaa ne pois vaikuttamatta mihinkään muuhun komponenttiin.

Tämä rakenne mahdollistaa Malli ja muut komponentit voivat kehittyä itsenäisesti, jolloin kehittäjät voivat työskennellä samanaikaisesti ratkaisun eri puolien kanssa. Esimerkiksi missä suunnittelijat työskentelevät näkymä, he vain tuottavat tietonäytteitä tarvitsematta käyttää muita komponentteja. Tämä helpottaa käyttöliittymän helppoa uudelleensuunnittelua näkymä on toteutettu XAML: ssä.

Kuten aiemmin mainittiin MVP, Yksinkertaiset ratkaisut eivät tarvitse arkkitehtuuria ja suunnittelumalleja, kuten ”Hei maailma!” on liian yksinkertainen seuraamaan kaikkia malleja; Koska uusia ominaisuuksia, toimintoja ja komponentteja otetaan käyttöön, sovelluksen monimutkaisuus kasvaa ja samoin hallittavan koodin määrä kasvaa.

Yhteenvetona

Käyttöliittymäkehityksen alusta lähtien suunnittelumallit ovat tulleet yhä suosituksi kehitysprosessin helpottamiseksi, sovellusten skaalautuvammaksi ja se helpottaa testaamista.

Kuvitettu ero MVP- ja MVVM-kuvioiden välillä:

  • Molemmissa MVP ja MVVM, näkymä on sovelluksen tulopiste
  • Sisään MVP, on yksi-yhteen kartoitus välillä näkymä ja Juontaja, missä sisään MVVM, suhde on monien välillä näkymä ja ViewModel.
  • MVP käytetään ensisijaisesti Windows-lomakkeisiin ja Windows Phone -sovelluksiin ja MVVM on suunniteltu Silverlight, WPF, Knockout / AngularJS jne.