Kuinka valita sopiva iOS-arkkitehtuuri (osa 2)

MVC, MVP, MVVM, VIPER tai VIP

Voit tutustua ensimmäiseen osaan täällä.

IOS: n tärkeimmät arkkitehtuurit

Lyhyt kuvaus.

MVC

MVC-kerrokset ovat seuraavat:

M: Liikelogiikka, verkkokerros ja tietojen käyttökerros

V: UI-kerros (UIKit-asiat, Kuvakäsikirjoitukset, Xibit)

C: Koordinoi sovittelun mallin ja näkymän välillä.

MVC: n ymmärtämiseksi meidän on ymmärrettävä konteksti, jossa se keksittiin. MVC keksittiin vanhoina verkkokehityspäivinä, jolloin Viewsilla ei ole tilaa. Vanhoina aikoina, kun tarvitsemme visuaalista muutosta verkkosivustossa, selain lataa koko HTML: n uudelleen. Tuolloin ei ollut käsitettä näkymätilan ylläpidosta ja tallentamisesta.

Oli esimerkiksi joitain kehittäjiä, jotka sekoittivat samaan HTML-tiedostoon, PHP: hen ja tietokantaan pääsyä. Joten MVC: n päämotivaatio oli erottaa View-kerros mallikerroksesta. Tämä lisäsi mallikerroksen testattavuutta. Oletettavasti MVC: ssä View- ja Model-taso ei saisi tietää mitään toisistaan. Jotta tämä olisi mahdollista, keksittiin välittäjäkerros nimeltä Controller. Tätä SRP: tä sovellettiin.

Esimerkki MVC-jaksosta:

  1. Käyttäjätoiminto / -tapahtuma näkymäkerroksessa (esim. Päivitä toiminta) potkaistaan ​​ja kyseinen toiminta ilmoitetaan ohjaimelle
  2. Ohjain, joka kysyy tietoja mallikerrokselle
  3. Malli palauttaa tiedot ohjaimelle
  4. Ohjain sanoo View-päivityksen päivittävän tilansa uudella datalla
  5. Näytä päivittää hänen tilaa

Apple MVC

IOS-käyttöjärjestelmässä View Controller on kytketty UIKit- ja elinkaarinäkymään, joten se ei ole puhdas MVC. MVC-määritelmässä ei kuitenkaan ole mitään sanottavaa, että ohjain ei voi tietää näkymä- tai mallikohtaista toteutusta. Hänen päätarkoituksensa on erottaa mallikerros vastuusta View-kerroksesta, jotta voimme käyttää sitä uudelleen ja testata mallikerroksen erikseen.

ViewController sisältää Näkymän ja omistaa mallin. Ongelma on, että meillä on tapana kirjoittaa sekä ohjaimen koodi että näkymän koodi ViewControlleriin.

MVC luo usein kutsutun Massive View Controller -ongelman, mutta vain niin tapahtuu ja siitä tulee vakava asia sovelluksissa, joilla on tarpeeksi monimutkaisuus.

On joitain menetelmiä, joita kehittäjä voi käyttää View Controller -sovelluksen hallittavuuden parantamiseksi. Joitain esimerkkejä:

  • Poistetaan VC-logiikka muille luokille, kuten taulukonäkymämenetelmien tietolähteelle, ja siirretään muille tiedostoille edustajan suunnittelumallin avulla.
  • Luo selkeämpi vastuualueiden jakautuminen kokoonpanon avulla (esim. Jaa VC lapsenäkymän ohjaimiin).
  • Koordinaattorin suunnittelumallin avulla voit poistaa vastuun navigointilogiikan toteuttamisesta VC: ssä
  • Käytä DataPresenter-kääreluokkaa, joka kapseloi logiikan ja muuntaa datamallin datalähdöksi, joka edustaa loppukäyttäjälle esitettyjä tietoja.

MVC vs. MVP

Se, miten näet MVP-kaavion, on hyvin samanlainen kuin MVC

MVC oli askel eteenpäin, mutta sitä leimasi silti poissaolo tai hiljaisuus joistakin asioista.

Samaan aikaan World Wide Web kasvoi ja monet asiat kehittäjien yhteisössä kehittyivät. Ohjelmoijat esimerkiksi aloittivat Ajaxin käytön ja lataavat vain osia sivuja koko HTML-sivun sijasta kerralla.

MVC: n mielestäni mikään ei tarkoita, että ohjaimen ei pitäisi tietää Näkymän (poissaolon) erityistä toteutusta.

HTML oli osa View-tasoa ja monet tapaukset olivat tyhmä kuin vittu. Joissain tapauksissa se vastaanottaa vain tapahtumia käyttäjältä ja näyttää graafisen käyttöliittymän visuaalisen sisällön.

Kun Web-sivujen osia alettiin ladata osiin, tämä segmentointi johti näkymätilan ylläpitämisen suuntaan ja esityslogiikan ja vastuun erottamisen suurempaan tarpeeseen.

Esityslogiikka on logiikka, joka ohjaa, kuinka käyttöliittymä tulee näyttää ja kuinka käyttöliittymäelementit ovat vuorovaikutuksessa. Esimerkki on ohjauslogiikka siitä, milloin lastausosoittimen pitäisi alkaa näyttää / animoida ja milloin sen pitäisi lopettaa näyttäminen / animointi.

MVP: ssä ja MVVM: ssä näkymäkerroksen tulisi olla tyhmä kuin vittu ilman mitään logiikkaa tai älykkyyttä siinä, ja iOS: ssä näkymäohjaimen tulisi olla osa näkymäkerrosta. Se, että Näkymä on tyhmä, tarkoittaa, että jopa esityslogiikka pysyy näkymäkerroksen ulkopuolella.

Yksi MVC: n ongelmista on, että ei ole selvää missä esityslogiikan tulisi pysyä. Hän vain hiljaa siitä. Pitäisikö esityslogiikan olla näkymäkerroksessa vai mallikerroksessa?

Jos mallin rooli on vain toimittaa ”raakatiedot”, se tarkoittaa, että näkymässä oleva koodi on:

Mieti seuraava esimerkki: meillä on käyttäjä, jolla on etunimi ja sukunimi. Näkymässä meidän on näytettävä käyttäjänimi nimellä ”Sukunimi, etunimi” (esim. “Flores, Tiago”).

Jos mallin rooli on toimittaa ”raakatiedot”, se tarkoittaa, että näkymässä oleva koodi on:

anna firstName = userModel.getFirstName ()
anna lastName = userModel.getLastName ()
nameLabel.text = lastName + “,“ + firstName

Tämä tarkoittaa, että Näkymän vastuulla on käyttöliittymälogiikan käsittely. Mutta tämä tekee käyttöliittymälogiikasta mahdotonta testata yksikköä.

Toinen tapa on saada malli paljastamaan vain ne tiedot, jotka on näytettävä, piilottaen kaikki liikelogiikat näkymästä. Mutta sitten päädymme malleihin, jotka käsittelevät sekä liike- että käyttöliittymälogiikkaa. Se olisi yksikkötestattavissa, mutta silloin malli päätyy epäsuorasti riippuvaiseksi Näkymästä.

anna nimi = userModel.getDisplayName ()
nameLabel.text = nimi

MVP on siitä selvä ja esityslogiikka pysyy Presenter-kerroksessa. Tämä lisää Presenter-kerroksen testattavuutta. Nyt malli- ja esittäjäkerros ovat helposti testattavissa.

Normaalisti MVP-toteutuksissa näkymä on piilotettu käyttöliittymän / protokollan taakse eikä Presenterissä pitäisi olla viittauksia UIKitiin.

Toinen asia, joka pitää mielessä, on transitiiviset riippuvuudet.

Jos rekisterinpitäjällä on riippuvuutena yrityskerros ja yrityskerroksella on tietoyhteyskerros riippuvuutena, niin ohjaimella on siirrettävä riippuvuus datakäyttökerroksesta. Koska MVP-toteutukset yleensä käyttävät sopimusta (protokollaa) kaikkien tasojen välillä, sillä ei ole transitiivisiä riippuvuuksia.

Eri kerrokset muuttuvat myös eri syistä ja eri nopeudella. Joten kun muutat kerrosta, et halua tämän aiheuttavan toissijaisia ​​vaikutuksia / ongelmia muissa kerroksissa.

Protokollat ​​ovat vakaampia kuin luokat. Protokollilla ei ole toteutustietoja ja sopimuksia, joten kerroksen toteutustietoja on mahdollista muuttaa vaikuttamatta muihin kerroksiin.

Joten sopimukset (protokollat) luovat erottamisen kerrosten välillä.

MVP vs. MVVM

MVVM-kaavio

Yksi tärkeimmistä eroista MVP: n ja MVVM: n välillä on se, että MVP: ssä Presenter kommunikoi näkymän kanssa rajapintojen kautta, ja MVVM: ssä View on suunnattu tietoihin ja tapahtumien muutoksiin.

Teemme MVP: ssä manuaalisen sidonnan Presenterin ja Viewin välille käyttöliittymien / protokollien avulla.
Teemme MVVM: ssä automaattisen datasidonnan käyttämällä jotain, kuten RxSwift, KVO, tai käytä mekanismia geneerisin ja sulkemisineen.

MVVM: ssä emme edes tarvitse sopimusta (esim .: Java-käyttöliittymä / iOS-protokolla) ViewModelin ja Viewn välillä, koska kommunikoimme yleensä Observer Design Pattern -sovelluksen kautta.

MVP käyttää valtuutettua mallia, koska Presenter-taso delegoi tilaukset näkymäkerrokseen, joten sen on tiedettävä jotain näkymästä, vaikka se olisi vain käyttöliittymän / protokollan allekirjoitus. Ajattele eroa Ilmoituskeskuksen ja TableView-edustajien välillä. Ilmoituskeskus ei tarvitse rajapintoja viestintäkanavan luomiseen, mutta TableView Delegates käyttää protokollaa, jonka luokkien tulisi toteuttaa.

Ajattele latausindikaattorin esityslogiikkaa. MVP: ssä ohjaaja tekee ViewProtocol.showLoadingIndicator. MVVM: ssä ViewModelissa voi olla isLoading-ominaisuus. Näytä kerros automaattisen datasidonnan avulla havaitsee, kun tämä ominaisuus muuttuu ja päivittää itsensä. MVP on välttämättömämpi kuin MVVM, koska Presenter antaa käskyjä.

MVVM liittyy enemmän datan muutoksiin kuin suoriin tilauksiin, ja teemme assosiaatioita datamuutosten ja näkymäpäivitysten välillä. Jos käytössä on RxSwift ja toiminnallinen reaktiivinen ohjelmointiparadigma yhdessä MVVM: n kanssa, olemme tehneet koodista vielä vähemmän välttämättömän ja deklaratiivisemman.

MVVM on helpompi testata kuin MVP, koska MVVM käyttää Observer Design Patterna, joka siirtää tietoja komponenttien välillä irrotettuna.
Joten voimme testata vain tarkastelemalla datan muutoksia vertaamalla kahta objektia sen sijaan, että luomme pilkkaavan menetelmäkutsuja testataksesi viestin Viewen ja Presenterin välillä.

PS: Tein artikkelissa joitain päivityksiä, jotka saivat artikkelin kasvamaan paljon, joten oli tarpeen jakaa se kolmeen osaan. Voit lukea kolmannen osan täältä.

Osa toinen päättyy tähän. Kaikki palautteet ovat tervetulleita. Kolmas osa puhuu VIPER: stä, VIP: sta, reaktiivisesta ohjelmoinnista, vaihtoista, rajoituksista ja kontekstuaalisuudesta.

Kiitos, että luit! Jos pidit tästä artikkelista, taputtele
Other jotta muut ihmiset voivat myös lukea sen :)