Tegye diétájába a nézetvezérlőjét MVVM kód weboldal fejlesztéssel, számítógépes játékokkal
- Megosztani Facebookon
- Csipog
- Megosztás a Google-on+
- Tétel a Tumblr-be
- Tűzd ki
- Hozzáadás a Pocket-hez
- Küldjön e-mailt
A sorozat utolsó hozzászólásában a Model-View-Controller mintáról és annak néhány hiányosságáról írtam. Annak ellenére, hogy az MVC egyértelmű előnyökkel jár a szoftverfejlesztés terén, a nagy vagy összetett kakaóalkalmazásokkal elmarad.
Ez azonban nem hír. Az évek során számos olyan építészeti minta jelent meg, amelyek a Model-View-Controller minta hibáit célozzák meg. Lehet, hogy hallottál róla MVP, Model-View-Presenter és MVVM, Például a Model-View-ViewModel. Ezek a minták hasonlítanak a Modell-Nézet-Vezérlő mintájára, de a Modell-Nézet-Vezérlő minta néhány problémájával is foglalkoznak.
1. Miért éppen a Model-View-ViewModel
Évek óta használtam a Model-View-Controller mintát, mielőtt véletlenül rábukkantam volna a modellre Model-View-ViewModel Sablon. Nem meglepő, hogy az MVVM a kakaó közösség leszármazottja, tekintve, hogy eredete a Microsoftra nyúlik vissza. Az MVVM mintázat azonban a kakaóba került, és a kakaó állványzat igényeihez és igényeihez igazodott, és a közelmúltban egyre nagyobb hangsúlyt kapott a kakaó közösségben.
A legvonzóbb, hogy az MVVM hogyan érzi magát a Model-View-Controller minta továbbfejlesztett változatának. Ez azt jelenti, hogy nem igényel drámai változást a gondolkodásmódban. Miután megértette a minta alapjait, elég egyszerűen kivitelezhető, nem nehezebb, mint a modell-nézet-vezérlő minta.
2. Tegye étrendre a View Controllert
Az előző bejegyzésben azt írtam, hogy egy tipikus Cocoa alkalmazás vezérlői kissé eltérnek azoktól a vezérlőktől, amelyeket Reenskaug az eredeti MVC mintában definiált. Például iOS rendszeren a nézetvezérlő vezérli a nézetet. Az Ön kizárólagos felelőssége az általa kezelt nézet kitöltése és a felhasználói interakciókra adott válasz. Ez azonban nem a View Controllers feladata a legtöbb iOS alkalmazásban?
Az MVVM minta egy negyedik komponenst vezet be a keverékbe, a Modell megjelenítése, amely segít a nézetvezérlő újrafókuszálásában. Ez a nézetvezérlő néhány felelősségének átvállalásával történik. Tekintse meg a következő ábrát, hogy jobban megértse, hogyan illeszkedik a nézet modell a Model-View-ViewModel mintába.
Amint az ábra mutatja, a nézetvezérlő már nem a modell tulajdonosa. A nézetmodell tulajdonosa a modellnek, és a nézetvezérlő a megjelenítési modellt kéri a megjelenítendő adatokhoz.
Ez egy fontos különbség a modell-nézet-vezérlő mintához képest. A nézetvezérlőnek nincs közvetlen hozzáférése a modellhez. A nézet modell megadja a nézetvezérlőnek azokat az adatokat, amelyekre szüksége van a nézetben való megjelenítéshez.
A Nézetvezérlő és a nézete közötti kapcsolat változatlan marad. Ez azért fontos, mert a nézetvezérlő a nézet kitöltésére és a felhasználói interakciók kezelésére összpontosíthat. A View Controller erre lett kifejlesztve.
Az eredmény elég drámai. A nézetvezérlő diétát tart, és sok felelősség áthárul a nézet modelljére. Végül már nincs olyan nézetvezérlő, amely több száz vagy akár több ezer kódsoron átívelne.
3. A vizuális modell felelőssége
Valószínűleg kíváncsi arra, hogyan illeszkedik a megtekintési modell a nagyobb képbe. Melyek a vizuális modell feladatai? Milyen a viszony a nézetvezérlővel? És mi van a modellel?
A diagram, amelyet korábban bemutattam nektek, néhány tippet ad nekünk. Kezdjük a modellel. A modell már nem tartozik a Nézetvezérlőhöz. A nézetmodell a modell tulajdonosa, és a nézetvezérlő proxyként működik. Amikor a nézetvezérlőnek szüksége van egy adatelemre a nézetmodelljéből, akkor megkéri a modelljét a nyers adatokra és formázza, hogy a nézetvezérlő azonnal felhasználhassa a nézetében. A nézetvezérlő nem felelős az adatok manipulálásáért és formázásáért.
A diagram azt is mutatja, hogy a modell a nézet modell tulajdonosa, nem a nézet vezérlője. Azt is meg kell jegyezni, hogy a Model-View-ViewModel minta figyelembe veszi a nézetvezérlő és a nézete közötti szoros kapcsolatot, amely jellemző a Cocoa alkalmazásokra. Emiatt az MVVM természetes választásnak érzi a kakaó alkalmazásokat.
4. Példa
Mivel a Model-View-ViewModel mintát nem tartalmazza a Cocoa, a minta végrehajtására nincsenek szigorú szabályok. Sajnos ezt sok fejlesztő megzavarja. Néhány dolog tisztázása érdekében szeretnék bemutatni egy alapvető példát egy alkalmazásra, amely az MVVM mintát használja. Egy nagyon egyszerű alkalmazást hozunk létre, amely az előre meghatározott hely időjárási adatait lekéri a Dark Sky API-ból, és megmutatja a felhasználónak az aktuális hőmérsékletet.
1. lépés: a projekt beállítása
Indítsa el az Xcode-ot, és hozzon létre egy új projektet a Single view alkalmazás Sablon. Az oktatóanyaghoz az Xcode 8 és a Swift 3 programokat használom.
Nevezze meg a projektet MVVM, és tedd nyelv nak nek Gyors és Eszközök nak nek iPhone.
2. lépés: Hozzon létre egy nézetmodellt
Egy tipikus Cocoa alkalmazásban, amely a modell-nézet-vezérlő mintát futtatja, a nézet vezérlő meg fogja tenni a hálózati kérést. A hálózati kérelem végrehajtásához használhatja a kezelőt, de a nézetvezérlő továbbra is tudná, honnan származnak az időjárási adatok. Ennél is fontosabb, hogy megkapja a nyers adatokat, és meg kell formáznia, mielőtt azok megjelennek a felhasználó számára. Ezt a megközelítést nem alkalmazzuk a Model-View-ViewModel minta átvételekor.
Hozzunk létre nézetmodellt. Hozzon létre egy új Swift fájlt, nevezze el WeatherViewViewModel.swift, és definiáljon egy WeatherViewViewModel nevű osztályt .
Az ötlet egyszerű. A nézetvezérlő a nézetmodelltől kéri az aktuális hőmérsékletet egy előre meghatározott helyre. Mivel a nézetmodell hálózati kérést küld a Dark Sky API-nak, a módszer elfogad egy zárat, amelyet akkor hívnak meg, amikor a nézetmodell rendelkezik adatokkal a nézetvezérlőhöz. Ez az adat lehet az aktuális hőmérséklet, de lehet hibaüzenet is. Így néz ki a nézetmodell StromTemperatur (befejezés:) В metódusa. Pillanatok alatt kitöltjük a részleteket.
Típusaliasnak nyilvánítjuk és meghatározzuk a StromTemperature (Completion:) metódust, amely elfogadja a CurrentTemperatureCompletion .В típus bezárását.
Nem nehéz megvalósítani, ha ismeri a hálózatot és az URLSession API-t. Vessen egy pillantást az alábbi kódra, és vegye észre, hogy felsorolt API-t használtam, hogy minden szép és tiszta legyen.
Az egyetlen kódrészlet, amelyet még nem mutattam meg, a hőmérséklet (a:) módszer megvalósítása. Ezzel a módszerrel kivonjuk az aktuális hőmérsékletet a Dark Sky válaszából.
Produkciós alkalmazásban robusztusabb megoldást választanék a válasz elemzésére, pl. B. ObjectMapper vagy Unbox.
3. lépés: Integrálja a nézet modelljét
Most már használhatjuk a nézet modelljét a nézet vezérlőben. Létrehozunk egy tulajdonságot a nézet modell számára, és három kimenetet is meghatározunk a felhasználói felülethez.
Vegye figyelembe, hogy a nézetmodell a nézetvezérlő tulajdonosa. Ebben a példában a nézetvezérlő felelős a nézetmodell példányosításáért is. Általában inkább a nézetmodellt injektálom a nézetvezérlőbe, de most tegyük csak meg.
A Vezérlő viewDidLoad () metódusban hívunk egy segítő metódust, a fetchWeatherData () .
A fetchWeatherData () fájlban a nézet modelljét kérdezzük meg az aktuális hőmérsékletről. Mielőtt lekérdeznénk a hőmérsékletet, elrejtjük a címkét és a gombot, és megmutatjuk az aktivitásjelzőt. A zárásnál továbblépünk a fetchWeatherData (Befejezés:) oldalra. Frissítjük a felhasználói felületet a hőmérsékleti címke kitöltésével és az aktivitásjelző elrejtésével.
A gomb egy fetchWeatherData (_:) művelettel van társítva, amelyben fetchWeatherData () helper metódust is hívunk. Mint láthatja, a segítő módszer segít elkerülni a kód duplikálását.
4. lépés: hozza létre a felhasználói felületet
A puzzle utolsó darabja a felhasználói felület létrehozása a minta alkalmazáshoz. Nyisd ki Alaplap és adjon hozzá egy címkét és gombot a függőleges verem nézethez. A veremnézet tetejére függőlegesen és vízszintesen középre kerül egy aktivitásjelző.
Ne felejtse el bekötni a kimeneteket és a ViewController osztályban definiált műveletet!
Most építse fel és indítsa el az alkalmazást, hogy megpróbálja. Ne feledje, hogy az alkalmazás működéséhez szüksége van egy Dark Sky API kulcsra. Regisztrálhat egy ingyenes fiókot a Dark Sky weboldalon.
5. Milyen előnyökkel jár?
Bár csak néhány apróbb dolgot mozgattunk a nézet modelljébe, elgondolkodhat azon, hogy miért van erre szükség. Mit nyertünk? Miért kellene hozzáadnia ezt az extra összetettségi réteget?
A legnyilvánvalóbb előny, hogy a nézetvezérlő karcsúbb és jobban összpontosít a nézet kezelésére. Ez a nézetvezérlő alapvető feladata: a nézet kezelése.
Van azonban finomabb előnye. Mivel a Nézetvezérlő nem felelős az időjárási adatok megszerzéséért a Dark Sky API-ból, nem ismeri a feladat részleteit. Az időjárási adatok származhatnak egy másik időjárási szolgálattól vagy egy gyorsítótárazott válaszból. A nézetvezérlőnek nem kellene és nem is kell tudnia.
A tesztelés is sokat javít. Ismeretes, hogy a nézetvezérlőket nehéz tesztelni, mivel szoros kapcsolatban vannak a nézősíkkal. Az üzleti logika egy részének a nézetmodellbe történő áthelyezésével azonnal javítjuk a projekt tesztelhetőségét. A nézetmodellek tesztelése meglepően egyszerű, mivel nincsenek linkjeik az alkalmazás nézettségi szintjéhez.
Következtetés
A Model-View-ViewModel minta jelentős előrelépés a kakaóalkalmazások tervezésében. A nézetvezérlők nem annyira kiterjedtek, a nézetmodelleket könnyebb összeállítani és tesztelni, és ez megkönnyíti a projekt munkáját.
Ebben a rövid sorozatban csak a felületet karcoltuk meg. Sokkal többet kell írni a Model-View-ViewModel mintáról. Az évek során az egyik kedvenc mintám lett, ezért beszélek és írok róla folyamatosan. Próbáld ki, és tudasd velem, mit gondolsz!
Addig is megnézheti a Swift és az iOS alkalmazások fejlesztésével kapcsolatos egyéb bejegyzéseinket.