Ставете го контролорот за преглед на диета со развој на веб-страница со кодот МВВМ, компјутерски игри

Сподели на Фејсбук
Чуруликам
Споделете на Google+
Објави на Тамблр
Закачете го
Додај во џеб
Испрати е-маил

Во мојот последен пост во оваа серија, напишав за моделот-Преглед-контролер на моделот и некои од нејзините несовршености. И покрај јасните предности што MVC ги носи во развојот на софтвер, тој не успева со големи или сложени апликации за какао.

Сепак, ова не е новост. Со текот на годините, се појавија неколку архитектонски обрасци кои се насочени кон недостатоците во моделот-Преглед-контролер на моделот. Можеби сте чуле за тоа МВП, Презентер за преглед на модел и МВВМ, На пример Model-View-ViewModel. Овие обрасци изгледаат и се чувствуваат слични на моделот Model-View-Controller, но тие исто така се осврнуваат и на некои проблеми што ги претставува моделот Model-View-Controller.

1. Зошто модел-преглед-преглед на модел

Ја користев шемата Model-View-Controller со години пред случајно да го сретнам моделот Модел со преглед на моделот Шаблон. Не е изненадувачки што МВВМ е потомок на заедницата Какао, со оглед на тоа што потеклото потекнува од Мајкрософт. Сепак, моделот MVVM е пренесен во Какао и прилагоден на барањата и потребите на скелето Какао, и неодамна се прослави во заедницата Какао.

Најатрактивно е како МВВМ се чувствува како надградена верзија на моделот-Преглед-контролер на моделот. Ова значи дека не бара драматична промена во начинот на размислување. Откако ќе ги разберете основите на моделот, тоа е прилично лесно да се спроведе, не е потешко од моделот-контролор за преглед на моделот.

2. Ставете Контролер за преглед на диета

Во претходниот пост напишав дека контролорите во типична апликација за какао се малку поинакви од контролорите што Реенскауг ги дефинираше во оригиналната шема на MVC. На пример, на iOS, контролорот за преглед контролира преглед. Ваша единствена одговорност е да го пополните прегледот со кој управува и да одговорите на интеракцијата на корисникот. Сепак, ова не е единствената работа на контролорите за преглед во повеќето апликации за iOS?

МВВМ моделот воведува четврта компонента во мешавината, Прикажи модел, што помага да се рефокусира контролорот за преглед. Ова се прави со преземање на некои од одговорностите на контролорот за преглед. Погледнете го следниот дијаграм за подобро да разберете како моделот View се вклопува во моделот Model-View-ViewModel.

Како што покажува дијаграмот, контролорот за преглед повеќе не го поседува моделот. Моделот за преглед е сопственик на моделот и контролорот за преглед го прашува моделот за преглед за да бидат прикажани податоците.

Ова е важна разлика од моделот-преглед на контролорот. Контролорот за преглед нема директен пристап до моделот. Моделот за преглед му ги дава на контролорот на прегледот податоците што треба да ги прикаже во поглед.

Односот помеѓу Контролорот за преглед и неговиот преглед останува непроменет. Ова е важно затоа што контролорот за преглед може да се фокусира на пополнување на неговиот преглед и управување со интеракцијата на корисникот. Контролорот за преглед е развиен за ова.

Резултатот е прилично драматичен. Контролорот за преглед се става на диета и многу одговорности се префрлаат на моделот на преглед. На крајот, веќе нема контролер за преглед кој опфаќа стотици или дури илјадници редови на код.

3. Одговорности на визуелниот модел

Веројатно се прашувате како моделот на гледање се вклопува во поголема слика. Кои се задачите на визуелниот модел? Како е односот со контролорот за преглед? А што е со моделот?

Дијаграмот што ви го покажав претходно ни дава неколку покажувачи. Да почнеме со моделот. Моделот повеќе не му припаѓа на контролорот за преглед. Моделот за преглед е сопственик на моделот и делува како полномошник за контролорот за преглед. Кога на контролорот за преглед му е потребен елемент на податок од неговиот модел на преглед, тој го прашува неговиот модел за необработените податоци и ги форматира така што контролорот за преглед може да го користи веднаш во неговиот поглед. Контролорот за преглед не е одговорен за манипулација и форматирање на податоците.

Дијаграмот исто така покажува дека моделот е во сопственост на моделот за преглед, а не за контролорот за преглед. Исто така, треба да се напомене дека моделот Model-View-ViewModel ја зема предвид тесната врска помеѓу контролорот за преглед и неговиот поглед, што е карактеристично за апликациите на какао. Поради ова, MVVM се чувствува како природен избор за апликации за какао.

4. Пример

Бидејќи моделот Model-View-ViewModel не е вклучен во Какао, нема строги правила за спроведување на моделот. За жал, ова се збунува од многу програмери. За да разјаснам неколку работи, сакам да ви покажам основен пример за апликација што ја користи моделот MVVM. Создаваме многу едноставна апликација што привлекува податоци за временските услови за претходно дефинирана локација од Dark Sky API и му ја покажува на корисникот моменталната температура.

Чекор 1: поставување на проектот

Започнете Xcode и креирајте нов проект заснован на Апликација со еден приказ Шаблон. Јас ги користам Xcode 8 и Swift 3 за ова упатство.

Наведете го проектот МВВМ, и стави јазик до Брзо и Уреди до iPhone.

Чекор 2: креирајте модел за преглед

Во типична апликација за какао која работи на моделот-Преглед-контролер на моделот, Контролорот за преглед ќе го направи мрежното барање. Можете да користите управувач за да го направите барањето за мрежа, но контролорот за преглед сè уште би знаел од каде доаѓаат податоците за времето. Што е уште поважно, ги прима необработените податоци и мора да ги форматира пред да бидат прикажани на корисникот. Ова не е пристапот што го користиме при усвојување на моделот Model-View-ViewModel.

Ајде да создадеме модел за преглед. Направете нова датотека Свифт, именувајте ја WeatherViewViewModel.swift, и дефинирајте класа наречена WeatherViewViewModel .

Идејата е едноставна. Контролорот за преглед го прашува моделот за преглед за моменталната температура за однапред дефинирана локација. Бидејќи моделот на преглед испраќа мрежно барање до Dark Sky API, методот прифаќа заклучување што се повикува кога моделот на преглед има податоци за контролорот за преглед. Овие податоци можат да бидат моментална температура, но може да бидат и порака за грешка. Така изгледа StromTemperatur (завршување:) В методот на прегледот. Detailsе ги пополниме деталите за неколку моменти.

Декларираме псевдоним за тип и дефинираме метод, StromTemperature (Завршување:), кој прифаќа затворање на CurrentTemperatureCompletion .В тип

Не е тешко да се имплементира ако сте запознаени со вмрежувањето и URLI-сесијата API. Погледнете го кодот подолу и забележете дека користев API-куршум за да одржам сè убаво и чисто.

Единственото парче код што сè уште не ви го покажав е спроведување на температурата (по:) метод. Во овој метод ја извлекуваме моменталната температура од одговорот на Темното небо.

Во производна апликација, би избрал поробусно решение за анализа на одговорот, на пр. B. ObjectMapper или Unbox.

Чекор 3: Интегрирајте го моделот за преглед

Сега можеме да го користиме моделот на преглед во контролорот за преглед. Ние создаваме својство за моделот на преглед и исто така дефинираме три излези за корисничкиот интерфејс.

Забележете дека контролорот за преглед е сопственик на моделот за преглед. Во овој пример, контролорот за преглед е исто така одговорен за инстанцирање на неговиот модел на преглед. Општо, претпочитам да го инјектирам моделот на преглед во контролорот за преглед, но ајде да го направиме тоа засега.

Во методот преглед viewDidLoad (), ние го нарекуваме метод на помошник, fetchWeatherData () .

Во fetchWeatherData (), го прашуваме моделот за приказ за моменталната температура. Пред да ја прашаме температурата, ги криеме етикетата и копчето и го покажуваме индикаторот за активност. Во затворањето, преминуваме на fetchWeatherData (Завршување:), го ажурираме корисничкиот интерфејс со пополнување на етикетата за температура и криење на индикаторот за активност.

Копчето е поврзано со акција, fetchWeatherData (_:), во која ние исто така го нарекуваме методот помошник на fetchWeatherData (). Како што можете да видите, методот помошник ни помага да избегнеме удвојување кодови.

Чекор 4: креирајте го корисничкиот интерфејс

Последното парче од сложувалката е создавање на кориснички интерфејс за примерочната апликација. Отворено Матична плоча и додадете етикета и копче во вертикален приказ на оџакот. Индикатор за активност се додава на горниот дел од приказот на оџакот, центриран вертикално и хоризонтално.

Не заборавајте да ги поврзете излезите и дејството што го дефиниравме во класата ViewController!

Сега изградете ја и стартувајте ја апликацијата за да пробате. Запомнете, ви треба Dark Sky API клуч за апликацијата да работи. Можете да се регистрирате за бесплатна сметка на веб-страницата на Темното небо.

5. Кои се придобивките?

Иако сме префрлиле само неколку ситни работи во моделот на преглед, можеби се прашувате зошто е тоа потребно. Што освоивме? Зошто треба да го додадете овој дополнителен слој на сложеност?

Најочигледна придобивка е што контролорот за преглед е послаб и пофокусиран на управување со неговиот преглед. Тоа е основната задача на контролорот за преглед: управување со неговиот преглед.

Но, има посуптилна корист. Бидејќи Контролорот за преглед не е одговорен за добивање на податоците за времето од Dark Sky API, тој не ги знае деталите за оваа задача. Податоците за времето може да доаѓаат од друга метеоролошка служба или од кеширан одговор. Контролорот за преглед не би морал и не мора да знае.

Тестирањето исто така многу подобрува. Познато е дека контролорите за преглед е тешко да се тестираат заради нивната блиска врска со рамнината за преглед. Со поместување на дел од деловната логика во моделот на преглед, ние веднаш ја подобруваме тестираноста на проектот. Тестирањето на моделите за преглед е изненадувачки лесно, бидејќи тие немаат врска до нивото на преглед на апликацијата.

Заклучок

Моделот Model-View-ViewModel е голем напредок во дизајнот на апликациите за какао. Контролорите за преглед не се толку обемни, моделите на преглед полесно се собираат и тестираат, а тоа го олеснува работењето на вашиот проект.

Во оваа кратка серија, само ја изгребавме површината. Има многу повеќе што треба да се напише за моделот Model-View-ViewModel. Стана еден од моите омилени обрасци со текот на годините, и затоа зборувам и пишувам за тоа цело време. Пробајте и кажете ми што мислите!

Во меѓувреме, можете да проверите некои други наши објави за развој на апликации Свифт и iOS.