Home-theater-designers
Nykyaikaiset sovellukset tarvitsevat niin erilaisia ominaisuuksia, että niiden kehitysprosessi on kasvanut kooltaan ja monimutkaisemmaksi. Avuksi voit käyttää arkkitehtonista suunnittelumallia. Ne tukevat sellaisten sovellusten rakentamista, joita on helppo testata ja ylläpitää.
Kolme suosituinta suunnittelumallia ovat MVC, MVP ja MVVM. MVC tarkoittaa mallia, näkymää ja ohjainta, kun taas MVP tarkoittaa mallia, näkymää ja esittäjää ja MVVM mallia, näkymää ja näkymämallia.
Arkkitehtuuri- ja suunnittelumallit
Arkkitehtoninen kuvio
Arkkitehtuurimalli selventää ja määrittelee joitain ohjelmistoarkkitehtuurin tärkeitä osia. Vaikka arkkitehtoninen kuvio välittää kuvan järjestelmästä, se ei ole arkkitehtuuria . Itse asiassa se on yleinen ja uudelleen käytettävä ratkaisu ohjelmistoarkkitehtuurissa yleisesti esiintyvään ongelmaan tietyssä kontekstissa.
Suunnittelumalli
Suunnittelumalli on formalisoitu paras käytäntö, jota voit käyttää yleisten ongelmien ratkaisemiseen sovellusta tai järjestelmää suunniteltaessa.
Ero arkkitehtonisen ja suunnittelumallin välillä
Aloitetaan yleisellä termillä - kuvio. Ohjelmistoissa kuvio on toistuva ominaisuus, jonka avulla voit hajottaa valtavan ja monimutkaisen rakenteen pienempiin, yksinkertaisempiin komponentteihin. Voit käyttää tätä mallia yleisen ratkaisun luomiseen ongelmaluokkaan.
Jokaisella ohjelmistokehityksen tasolla käytät erilaisia työkaluja. Pienemmillä tasoilla nämä työkalut ovat suunnittelumalleja. Arkkitehtonisia malleja on olemassa suuremmilla tasoilla ja ohjelmointiparadigmat täytäntöönpanon tasolla.
Miksi tarvitsemme arkkitehtonisia suunnittelumalleja?
Ohjelmistokehityksen aikana voit käyttää arkkitehtonisia suunnittelumalleja yleisten ongelmien ratkaisemiseen. Hyvä arkkitehtuuri voi myös auttaa:
- Jaa monimutkaiset tehtävät yksinkertaisempiin tehtäviin.
- Vähennä bugeja.
- Tuota testattavaa ja ylläpidettävää koodia.
Mutta ilman arkkitehtonista mallia saatat kohdata vaikeuksia ylläpitää sovelluksesi liiketoimintalogiikkaa.
Malli, View, ViewModel, Controller ja Presenter
Ennen kuin tarkastelet kutakin mallia, tässä ovat termit, joista ne muodostuvat:
- Malli tallentaa tietoja ja kommunikoi suoraan tietokannan kanssa. Malli on osa, joka edustaa tietojasi ja sovelluslogiikkaasi. Se määrittelee liiketoimintasäännöt, jotka hallitsevat tietojen käsittelyä, muokkaamista tai käsittelyä.
- Näytä näyttää mallin tiedot ja vastaa tietojen esittämisestä käyttöliittymässä.
- ViewModel on yksinomaan MVVM-mallissa. Tämä on näkymäkerroksen abstraktio ja toimii myös mallitietojen kääreenä.
- Ohjain on komponentti, joka yhdistää näkymän ja mallin.
- Juontaja on komponentti, joka on olemassa vain MVP-mallissa. Esittäjä saa syötteen näkymäkomponentilta ja käsittelee tiedot mallin avulla.
MVC-, MVP- ja MVVM-mallit
Malli-näkymä-ohjain-kuvio
The MVC arkkitehtoninen kuvio oli ensimmäinen, ja se on nykyään suosittu verkkosovellusten alalla. Se otettiin käyttöön 1970-luvulla. Tämän mallin avulla voit rakentaa sovelluksen Separation of Concernin (SoC) ympärille. Se helpottaa sovelluksesi testaamiseen, ylläpitoon ja kehittämiseen tarvittavaa työtä.
kuinka poistaa live -ilmoitukset käytöstä Facebook -sovelluksessa
MVC-kuviossa malli ei ymmärrä näkymää tai ohjainta. Mallin tarkkailija saa hälytyksen aina, kun näkymässä ja ohjaimessa tapahtuu muutos. Ohjain auttaa reititysprosessia yhdistämään mallin asiaankuuluvaan näkymään.
Jotkut MVC-kuvion eduista ovat:
- Huolenaiheiden erottaminen (keskittyneempi).
- Helpottaa koodin testaamista ja hallintaa.
- Edistää sovelluksen tasojen irrottamista.
- Parempi koodin organisointi ja uudelleenkäytettävyys.
Näin MVC toimii:
SoC:n ansiosta MVC voi pienentää koodin kokoa ja tehdä hyvän koodin, joka on puhdas ja hallittavissa.
Malli-näkymä-Esittäjä-kuvio
MVP-kuvio jakaa kaksi osaa MVC:n kanssa: malli ja näkymä. Se korvaa ohjaimen esittäjällä. Esittäjä - kuten sen nimi kertoo - käytetään esittämään jotain. Sen avulla voit pilkata näkymää helpommin.
MVP:ssä esittäjällä on 'välimiehen' toiminnallisuus, koska kaikki esityslogiikka työnnetään siihen. MVP:n näkymä ja esittäjä ovat myös toisistaan riippumattomia ja ovat vuorovaikutuksessa käyttöliittymän kautta.
Tässä on esimerkki siitä, kuinka MVP-kuvio toimii:
Esittäjä saa syötteitä käyttäjältä näkymän kautta. Sitten se käsittelee käyttäjän toimet mallin avulla ja välittää tulokset takaisin näkymään. Esittäjä kommunikoi näkymän kanssa käyttöliittymien kautta.
Malli-näkymä-näkymämallimalli
MVVM on MVC:n moderni kehitys. MVVM:n päätavoite on tarjota selkeä ero toimialueen logiikan ja esityskerroksen välillä. MVVM tukee kaksisuuntaista tiedonsidontaa näkymän ja näkymämallin välillä.
MVVM-mallin avulla voit erottaa koodin näkymän ja mallin. Tämä tarkoittaa, että kun malli muuttuu, näkymää ei tarvitse tehdä ja päinvastoin. Näkymämallin avulla voit tehdä yksikkötestauksen ja testata logiikkakäyttäytymistäsi ilman näkymääsi.
Tässä on esimerkki MVVM:n toiminnasta:
Milloin käyttää MVC:tä, MVP:tä ja MVVM:ää
Nyt kun olet oppinut jokaisesta mallista, ota selvää, milloin niitä tulee käyttää.
Milloin käyttää MVC:tä
MVC on yksinkertaisesti Toteutus Separation of Concerns. Jos sovelluksesi täytyy erottaa tiedot (malli), tietojen murskaus (ohjain) ja tietojen esitys (näkymä), MVC toimii hyvin. MVC toimii hyvin myös sovelluksessa, jossa tietolähde ja/tai tiedon esitystapa voivat muuttua milloin tahansa.
Milloin käyttää MVP:tä
Voit käyttää MVP:tä, kun sovelluksessasi on kaksisuuntainen virtaus. Jos käyttäjien on pyydettävä jotain mallilta ja tämän pyynnön tulos muuttaa käyttöliittymää välittömästi, harkitse MVP:tä.
Milloin käyttää MVVM:ää
Haluat käyttää MVVM:ää, kun:
- Sinun tulee jakaa projekti suunnittelijan kanssa ja suunnittelu- ja kehitystyö voi tapahtua itsenäisesti.
- Tarvitset yksikkötestauksen ratkaisuillesi.
- Sinulla on oltava uudelleenkäytettäviä komponentteja sekä organisaatiossasi että projekteissasi.
- Haluat enemmän joustavuutta muuttaaksesi näkemyksiäsi ilman, että sinun tarvitsee muuttaa koodikannan muuta logiikkaa.
Mikä malli kannattaa valita?
Tärkein syy suunnittelumallin käyttöön on monimutkaisuuden vähentäminen. Voit tehdä tämän vähentämällä yleistä monimutkaisuutta tai korvaamalla tuntemattoman monimutkaisuuden tutulla. Jos suunnittelukuvio ei voi vähentää monimutkaisuutta kummallakaan näistä tavoista, älä käytä kumpaakaan. se ei tuo mitään lisäarvoa.
Jos olet todella varma, että sinun pitäisi käyttää suunnittelukuviota, yritä tehdä tarkistuslista. Perustele se täällä näkemiesi tilanteiden perusteella ja valitse projektiisi parhaiten sopiva.