VIPER-suunnittelumalli Swift-sovelluksessa iOS-sovellusten kehittämiseen.

Kaikella, jolla on alku, on loppu - Gautama Buddha. Kuvalähde: Kuvakaappaus elokuvasta “Matrix Revolutions”

Suunnittelumallit ovat Jumalan lahja ohjelmistokehittäjille. Nämä ovat tekniikoita, jotka minimoivat koodin kopioinnin, estävät korkean kytkemisen ja standardisoivat yleisen tavan kirjoittaa koodi, joka tarjoaa yleisen ratkaisun toistuvaan tilanteeseen ohjelmistoa kehitettäessä. Tässä tarinassa tutustumme VIPER-malliin (View, Interactor, Presenter, Entity and Router.) IOS-kehitykseen.

Edellytykset: Ennen kuin aloitat VIPER: n aloittamisen, varmista, että tiedät arkkitehtisuunnittelumallin ja valtuuskunnan rakenteen.

Mikä on Viper?

Viper on suunnittelumalli, joka toteuttaa 'huolen erottamisen' paradigman. Useimmiten kuten MVP tai MVC, se noudattaa modulaarista lähestymistapaa. Yksi ominaisuus, yksi moduuli. Kullakin moduulilla VIPER: llä on viisi (joskus neljä) eri luokkaa, joilla on erilliset roolit. Mikään luokka ei ylitä sen ainoata tarkoitusta. Nämä luokat seuraavat.

Näkymä: luokka, jolla on kaikki koodit sovelluksen käyttöliittymän näyttämiseksi käyttäjälle ja heidän vastausten saamiseksi. Saatuaan vastauksen View hälyttää esittelijää.

Juontaja: Moduulin ydin. Se saa käyttäjän vastauksen näkymästä ja toimii sen mukaisesti. Vain luokka kommunikoida kaikkien muiden komponenttien kanssa. Soittaa reitittimelle langankehystämistä varten, Interactor hakea tietoja (verkkopuhelut tai paikalliset datapuhelut), jotta käyttöliittymä päivitetään.

Interactor: Sisältää sovelluksen liiketoimintalogiikan. Soita ensisijaisesti API-kutsuja tietojen noutamiseksi lähteestä. Vastuu datapuhelujen soittamisesta, mutta ei välttämättä itsestään.

Reititin: Rajoittaako lanka. Kuuntelee esittäjän esittämää näyttöä ja suorittaa sen.

Kokonaisuus: Sisältää vuorovaikuttajan käyttämät tavalliset mallilajit.

Alla on esitetty yksinkertainen VIPER-kaavio

Viper-arkkitehtuuri

Viper esimerkillä

Olen luonut yksinkertaisen projektin viperin selittämiseksi. Se löytyy GitHubista. Se on hyvin yksinkertainen sovellus, joka näyttää uutisotsikon, joka on haettu ulkoisesta sovellusliittymästä. (kuinka hyödytöntä: p).

Viper on valtuuskunnan ohjaama arkkitehtuuri. Joten suurin osa eri kerrosten välisestä viestinnästä tapahtuu delegoinnin kautta. Yksi kerros soittaa toiselle protokollan kautta. Soittamiskerros kutsuu toimintoa protokollasta. Kuuntelukerros on kyseisen protokollan mukainen ja toteuttaa toiminnon.

Seuraavaksi selitän kuinka olen toteuttanut VIPERin yhdessä esimerkkihankkeessani. Ehdotan, että avaat projektin githubissa ja käy sen läpi lukeessasi selitystä.

protokollat

Olen luonut erillisen tiedoston kaikille protokollille.

Protokollan nimeämiseksi noudatetaan nimeämiskäytäntöä. E.g, 'viewToPresenterProtocol'. Joten, se on 'protokolla', jonka 'esittäjä' toteuttaa kuuntelemaan 'näkemyksen' sanoja.

  • PresenterToViewProtocol: Presenter-puhelut, Näytä kuuntelut. Presenter vastaanottaa viittauksen tästä protokollasta katselun käyttämiseksi. Näytä on protokollan mukainen.
  • ViewToPresenterProtocol: Näytä puhelut, Presenter kuuntelee.
  • InteractorToPresenterProtocol: Interaktoripuhelut, Presenter kuuntelee.
  • PresentorToInteractorProtocol: Presenter soittaa, Interactor kuuntelee.
  • PresenterToRouterProtocol: Presenter soittaa, Router kuuntelee.

Sovellusvirta

View-sovelluksessa on viittaus ViewToPresenterProtocol -sovellukseen päästäksesi Presenter-sovellukseen ja vastaavaksi PresenterToViewProtocol -sovellusta. Sen mukaanDidLoad () kutsuu protokollan funktiota updateView ().

// View
var presenter: ViewToPresenterProtocol?
ohita func viewDidLoad () {
   super.viewDidLoad ()
   juontaja? .updateView ()
}

Esittäjä puolestaan ​​noudattaa ”ViewToPresenterProtocol” -standardia. Joten se toteuttaa updateView () -toiminnon.

//Juontaja
var vuorovaikutus: PresentorToInteractorProtocol ?;
func updateView () {
   Interactor? .fetchLiveNews ()
}

UpdateView () -juontaja sisältää käskyn vuorovaikuttajalle hakea joitain live-uutisia.

Interaktori on 'PresentorToInteractorProtocol'. Joten se toteuttaa fetchLiveNews () -toiminnon. Tämä toiminto yrittää soittaa verkkopuhelun ja hakea tietoja. Sillä on viittaus InteractorToPresenterProtocol -sovelluksesta päästäksesi Presenteriin.

// Interactor
var esittäjä: InteractorToPresenterProtocol?

Jos verkkopuhelu on onnistunut noutamaan tiedot, se kutsuu seuraavaa toimintoa.

// Interactor
itse.esittäjä? .liveNewsFetched (uutiset: (arrayObject? [0])!)

jos ei

// Interactor
self.presenter? .liveNewsFetchedFailed ()

Nyt esittäjä noudattaa myös ”InteractorToPresenterProtocol” -standardia. Joten se toteuttaa nämä toiminnot.

//juontaja
func liveNewsFetched (uutiset: LiveNewsModel) {
        Näytä? .showNews (uutiset: uutiset);
}
func liveNewsFetchedFailed () {
        view? .showError ()
}

Joten se kertoo näkymälle, näytetäänkö uutisia vai näytetäänkö virhe.

Nyt View on "PresenterToViewProtocol" -standardin mukainen. Siten se toteuttaa showNews () ja showError (). Näissä kahdessa toiminnossa näkymä täyttää näkymän noudun datan tai virheen kanssa.

Kokonaisuuskerros

Edellä sovellusvirtausosion entiteettikerroksessa ei keskustella. Se ei liity suoraan sovellusvirtaan. Mutta se on olennainen osa vuorovaikuttajaa. Kokonaisuuskerros tarjoaa mallin, jota vuorovaikuttaja käyttää objektien luomiseen noudetuista tiedoista.

reititin

Reititin huolehtii sovelluksen langankehyksestä. Näytön vaihtaminen sovelluksessa on hyvin perusasia. VIPER: ssä Router-kerros on vastuussa tämän suorittamisesta.

Olemme aiemmin keskustelleet siitä, että VIPER-arkkitehtuurissa jokaisella toiminnallisuudella on yksi moduuli ja moduuli sisältää nämä viisi kerrosta. Juontaja soittaa reitittimelle uuden moduulin luomiseksi. Sitten reititin aloittaa ensin kaikki kerrosluokat ja palauttaa moduulin.

Oman projektiprojektini sisällä ei ole sovelluksen sisäistä moduulia vaihtamassa. Mutta reititys tapahtuu, kun sovellus käynnistyy ensimmäisen kerran. Joten AppDelegaten 'didFinishLaunchingWithOptions ()': ssa, reitittimen createModule () -toimintoa kutsutaan. Se palauttaa moduulin. UIWindow-luokka näyttää sitten kyseisen moduulin näkymän.

Miksi ja milloin VIPER: ää käytetään

VIPER noudattaa erittäin puhdasta arkkitehtuuria. Se eristää jokaisen moduulin muista. Joten virheiden muuttaminen tai korjaaminen on erittäin helppoa, koska sinun on päivitettävä vain tietty moduuli. Myös modulaarisen lähestymistavan avulla VIPER luo erittäin hyvän ympäristön yksikkötestaukseen. Koska jokainen moduuli on toisistaan ​​riippumaton, se ylläpitää erittäin matalaa kytkentää. Joten työn jakaminen yhteistyössä kehittäjien välillä on melko yksinkertaista.

VIPER: ää tulisi käyttää, kun sovelluksen vaatimukset ovat erittäin hyvin muotoiltuja. Jatkuvasti muuttuvien vaatimusten kanssa työskenteleminen voi aiheuttaa sekaannusta ja sekoittaa koodeja. Joten sitä ei tule käyttää pienessä projektissa, koska MVP tai MVC riittävät. Lisäksi VIPER: ää tulisi käyttää, jos kaikki projektin kehittäjät ymmärtävät mallin täysin.

VIPER-työkalut

Jos halutaan käyttää VIPER-hanketta projektissa, fiksin asia olisi käyttää automaattista moduulirakennegeneraattoria. Muuten tiedostojen luominen moduuleille on yksitoikkoista. Muutamia generaattoreita on saatavana verkossa.

  • Generamba
  • VIPER-koodi
  • VIPER yl

johtopäätös

Kuten kaikki muutkin suunnittelumallit, VIPER on itsestään selvä. Koko kuvan ymmärtämiseksi täytyy kädet likaantua. Neuvoni on ensin aloittaa luomalla hyvin perussovellus VIPER: llä ja lukemalla prosessissa verkkoresurssi. Github-repooni voi myös olla hyvä viite.

Hyvää koodausta :)

Eläköön pyhä Bangladesh.

Bangladesh on metafora, korkean ja matalan teatterin, suuren runouden ja musiikin maailma. Puhut riisinviljelijän kanssa ja löydät runoilijan. Tutustut katujen lakaisijaan ja löydät merkittävän laulajan.
Jean Houston

Viite:

  1. https://medium.com/ios-os-x-development/ios-architecture-patterns-ecba4c38de52
  2. https://medium.com/@ankoma22/the-good-the-bad-and-the-ugly-of-viper-architecture-for-ios-apps-7272001b5347
  3. https://github.com/MindorksOpenSource/iOS-Viper-Architecture/tree/master/iOS-Viper-Architecture
  4. https://sourcemaking.com/design_patterns