Dajte svojmu kontroléru pohľadu na diétu s vývojom webových stránok s kódom MVVM, počítačovými hrami

• Zdielať na Facebook-u
• Tweet
• Zdieľajte na Googli+
• Uverejniť na Tumblr
• Pripnúť
• Pridať do vrecka
• Poslať email

V mojom poslednom príspevku v tejto sérii som písal o vzore Model-View-Controller a niektorých jeho nedokonalostiach. Napriek jasným výhodám, ktoré spoločnosť MVC prináša vývoju softvéru, nedosahuje veľké alebo zložité kakaové aplikácie.

Nie sú to však novinky. V priebehu rokov sa objavilo niekoľko architektonických vzorov, ktoré sa zameriavajú na chyby vzoru Model-View-Controller. Možno ste už o tom počuli MVP, Model-View-Presenter a MVVM, Napríklad Model-View-ViewModel. Tieto vzory vyzerajú a vyzerajú podobne ako vzor Model-View-Controller, ale tiež riešia niektoré problémy, ktoré vzor Model-View-Controller predstavuje.

1. Prečo Model-View-ViewModel

Vzor Model-View-Controller som používal roky, kým som sa k modelu náhodou nedostal Model-View-ViewModel Šablóna. Nie je prekvapením, že MVVM je potomkom kakaovej komunity, keďže jej počiatky siahajú až do spoločnosti Microsoft. Avšak vzor MVVM bol prenesený na kakao a prispôsobený požiadavkám a potrebám kakaového lešenia a nedávno sa dostal do popredia v kakaovej komunite.

Najatraktívnejšie je, ako sa MVVM cíti ako upgradovaná verzia modelu Model-View-Controller. To znamená, že to nevyžaduje dramatickú zmenu myslenia. Keď pochopíte základné informácie o tomto modeli, jeho implementácia je celkom ľahká, nie zložitejšia ako vzor modelu - pohľadu - radiča.

2. Dajte View Controller na diétu

V predchádzajúcom príspevku som napísal, že radiče v typickej aplikácii Cocoa sa trochu líšia od radičov, ktoré Reenskaug definoval v pôvodnom vzore MVC. Napríklad v systéme iOS ovláda zobrazenie kontrolér pohľadu. Výlučnou zodpovednosťou je vyplniť pohľad, ktorý spravuje, a reagovať na interakciu používateľov. Toto však nie je jediná práca ovládačov zobrazenia vo väčšine aplikácií pre iOS?

Vzor MVVM zavádza do zmesi štvrtú zložku, a to Zobraziť model, ktorý pomáha znovu zaostriť radič zobrazenia. To sa deje prevzatím časti zodpovednosti kontrolóra pohľadu. Prezrite si nasledujúci diagram, aby ste lepšie pochopili, ako model zobrazenia zapadá do vzoru Model-View-ViewModel.

Ako ukazuje schéma, radič pohľadu už nevlastní model. Model zobrazenia vlastní model a radič zobrazenia požiada model zobrazenia o údaje, ktoré sa majú zobraziť.

Toto je dôležitý rozdiel od vzoru model-pohľad-radič. Ovládač pohľadu nemá priamy prístup k modelu. Model zobrazenia poskytuje radiču zobrazenia údaje, ktoré potrebuje na zobrazenie vo svojom zobrazení.

Vzťah medzi kontrolórom zobrazenia a jeho zobrazením zostáva nezmenený. To je dôležité, pretože kontrolér pohľadu sa môže sústrediť na vyplnenie svojho pohľadu a manipuláciu s interakciou používateľa. Pre tento účel bol vyvinutý View Controller.

Výsledok je dosť dramatický. Ovládač pohľadu je držaný na diéte a veľa zodpovedností je presunutých na model pohľadu. Nakoniec už neexistuje radič zobrazenia, ktorý obsahuje stovky alebo dokonca tisíce riadkov kódu.

3. Zodpovednosti vizuálneho modelu

Pravdepodobne by vás zaujímalo, ako sa model pozerania hodí k väčšiemu obrazu. Aké sú úlohy vizuálneho modelu? Aký je vzťah s kontrolórom pohľadu? A čo modelka?

Schéma, ktorú som vám ukázal predtým, nám dáva niekoľko ukazovateľov. Začnime s modelom. Model už nepatrí do radiča zobrazenia. Model zobrazenia vlastní model a slúži ako proxy pre radič zobrazenia. Keď radič zobrazenia potrebuje dátový prvok zo svojho modelu zobrazenia, požiada svoj model o nespracované údaje a naformátuje ich tak, aby ich mohol radič zobrazenia okamžite použiť vo svojom zobrazení. Kontrolór zobrazenia nezodpovedá za manipuláciu a formátovanie údajov.

Diagram tiež ukazuje, že model vlastní model zobrazenia, nie radič zobrazenia. Je tiež potrebné poznamenať, že vzor Model-View-ViewModel zohľadňuje úzky vzťah medzi radičom pohľadu a jeho pohľadom, ktorý je charakteristický pre kakaové aplikácie. Z tohto dôvodu sa MVVM cíti ako prirodzená voľba pre kakaové aplikácie.

4. Príklad

Pretože vzor Model-View-ViewModel nie je zahrnutý v kakau, neexistujú žiadne prísne pravidlá pre implementáciu vzoru. Mnoho vývojárov to bohužiaľ pletie. Na objasnenie niekoľkých vecí vám chcem ukázať základný príklad aplikácie, ktorá používa vzor MVVM. Vytvárame veľmi jednoduchú aplikáciu, ktorá z rozhrania Dark Sky API stiahne údaje o počasí pre vopred definované miesto a zobrazí používateľovi aktuálnu teplotu.

Krok 1: nastavenie projektu

Spustite Xcode a vytvorte nový projekt založený na Aplikácia na jedno zobrazenie Šablóna. Pre tento tutoriál používam Xcode 8 a Swift 3.

Pomenujte projekt MVVM, a dať Jazyk do Rýchlo a Zariadenia do iPhone.

Krok 2: Vytvorte model zobrazenia

V typickej kakaovej aplikácii so vzorom Model-View-Controller by radič zobrazenia urobil požiadavku na sieť. Na vykonanie žiadosti o sieť môžete použiť správcu, ale radič zobrazenia by stále vedel, odkiaľ pochádzajú údaje o počasí. Dôležitejšie je, že prijíma nespracované údaje a pred ich zobrazením používateľovi ich musí naformátovať. Toto nie je prístup, ktorý používame pri prijímaní vzoru Model-View-ViewModel.

Vytvorme model pohľadu. Vytvorte nový súbor Swift, pomenujte ho WeatherViewViewModel.swift, a definujte triedu s názvom WeatherViewViewModel .

Myšlienka je jednoduchá. Ovládač zobrazenia požiada model zobrazenia o aktuálnu teplotu pre vopred definované miesto. Pretože model zobrazenia odosiela požiadavku na sieť do rozhrania Dark Sky API, metóda prijíma zámok, ktorý sa volá, keď má model zobrazenia údaje pre radič zobrazenia. Týmito údajmi môže byť aktuálna teplota, ale môže ísť aj o chybové hlásenie. To je to, čo metóda StromTemperatur (dokončenie:) В modelu zobrazenia vyzerá takto. O pár okamihov doplníme podrobnosti.

Deklarujeme alias typu a definujeme metódu StromTemperature (Dokončenie:), ktorá akceptuje uzavretie typu CurrentTemperatureCompletion.

Nie je ťažké ho implementovať, ak ovládate prácu v sieti a rozhranie API URLSession. Prezrite si nižšie uvedený kód a všimnite si, že som použil vymenované API, aby bolo všetko pekné a čisté.

Jediný kúsok kódu, ktorý som vám ešte neukázal, je implementácia metódy temperature (by:). V tejto metóde extrahujeme aktuálnu teplotu z odozvy Temnej oblohy.

V produkčnej aplikácii by som na analýzu odpovede vybral robustnejšie riešenie, napr. B. ObjectMapper alebo Unbox.

Krok 3: Integrujte model zobrazenia

Teraz môžeme používať model zobrazenia v ovládači zobrazenia. Vytvárame vlastnosť pre model zobrazenia a tiež definujeme tri východy pre užívateľské rozhranie.

Upozorňujeme, že radič pohľadu vlastní model pohľadu. V tomto príklade je radič zobrazenia tiež zodpovedný za vytvorenie inštancie svojho modelu zobrazenia. Spravidla dávam prednosť zavedeniu modelu zobrazenia do ovládača zobrazenia, ale urobme to zatiaľ.

V metóde pohľadu Controller viewDidLoad () voláme pomocnú metódu, fetchWeatherData () .

V programe fetchWeatherData () sa modelu zobrazenia pýtame na aktuálnu teplotu. Pred dotazom na teplotu skryjeme štítok a tlačidlo a zobrazíme indikátor aktivity. V závere prejdeme na fetchWeatherData (Dokončenie:), Aktualizujeme užívateľské rozhranie vyplnením štítku teploty a skrytím indikátora aktivity.

Tlačidlo je spojené s akciou fetchWeatherData (_:), pri ktorej voláme aj pomocnú metódu fetchWeatherData (). Ako vidíte, pomocná metóda nám pomáha vyhnúť sa duplikácii kódu.

Krok 4: Vytvorte používateľské rozhranie

Poslednou časťou skladačky je vytvorenie používateľského rozhrania pre vzorovú aplikáciu. Otvorené Základná doska a pridajte štítok a tlačidlo do zvislého pohľadu na zásobník. Do hornej časti zobrazenia zásobníka sa pridá indikátor aktivity, ktorý je vycentrovaný vertikálne a horizontálne.

Nezabudnite zapojiť výstupy a akciu, ktorú sme definovali v triede ViewController!

Teraz si aplikáciu vyskúšajte zostavením a spustením. Nezabudnite, že na to, aby aplikácia fungovala, potrebujete kľúč API Dark Sky. Na webe Dark Sky sa môžete zaregistrovať na bezplatný účet.

5. Aké sú výhody?

Aj keď sme do modelu zobrazenia presunuli iba niekoľko drobných vecí, možno by vás zaujímalo, prečo je to nevyhnutné. Čo sme vyhrali? Prečo by ste mali pridať túto ďalšiu vrstvu zložitosti?

Najviditeľnejšou výhodou je, že ovládač pohľadu je štíhlejší a viac zameraný na správu svojho pohľadu. To je hlavná úloha kontrolóra pohľadu: správa jeho pohľadu.

Existuje však jemnejšia výhoda. Pretože View Controller nie je zodpovedný za získavanie údajov o počasí z Dark Sky API, nevie podrobnosti o tejto úlohe. Údaje o počasí môžu pochádzať z inej meteorologickej služby alebo z odpovede v pamäti. Ovládač pohľadu by to nemusel a nemusí vedieť.

Testovanie tiež veľa vylepšuje. Je známe, že kontroléry pohľadu sa ťažko testujú kvôli ich blízkemu vzťahu s rovinou pohľadu. Presunutím časti obchodnej logiky do modelu zobrazenia okamžite zlepšujeme testovateľnosť projektu. Testovanie modelov zobrazenia je prekvapivo ľahké, pretože nemajú odkaz na úroveň zobrazenia aplikácie.

Záver

Vzor Model-View-ViewModel je hlavným pokrokom v dizajne kakaových aplikácií. Ovládače zobrazenia nie sú také veľké, modely zobrazenia sa ľahšie zostavujú a testujú, čo uľahčuje správu vášho projektu.

V tejto krátkej sérii sme poškriabali iba povrch. O vzore Model-View-ViewModel sa dá toho napísať oveľa viac. Za tie roky sa stal jedným z mojich obľúbených vzorov, a preto o ňom neustále hovorím a píšem. Vyskúšajte to a dajte mi vedieť, čo si myslíte!

Medzitým si môžete pozrieť niektoré z našich ďalších príspevkov o vývoji aplikácií Swift a iOS.

---