Како одабрати одговарајућу иОС архитектуру (2. део)

МВЦ, МВП, МВВМ, ВИПЕР или ВИП

Овдје можете конзултирати први дио.

Главне иОС архитектуре

Кратак преглед.

МВЦ

МВЦ слојеви су следећи:

М: Пословна логика, мрежни слој и слој приступа подацима

В: Слој УИ (ствари УИКит, Сторибоардс, Ксибс)

Ц: Координира посредовање између модела и погледа.

Да бисмо разумели МВЦ, морамо разумети контекст у којем је измишљен. МВЦ је измишљен у старим данима веб развоја, где Виевс нема стање. У стара времена када нам је потребна визуелна промена на веб локацији, прегледач поново учитава цео ХТМЛ. У то време није постојао концепт стања погледа и одржавања.

На пример, било је неких програмера који су се мешали унутар исте ХТМЛ датотеке, ПХП-а и приступа бази података. Дакле, главна мотивација МВЦ-а била је одвајање слоја Виев од слоја модела. Ово је повећало проверљивост слоја модела. Наводно у МВЦ-у, слој Виев и Модел не треба да знају ништа једни о другима. Да би ово било могуће, изумљен је посреднички слој под називом Цонтроллер. Ово је био СРП који је примењен.

Пример циклуса МВЦ:

  1. Корисничка акција / догађај у Лаиер-у за приказ (нпр .: Освежи акцију) покреће се и та акција се прослеђује Цонтроллер-у
  2. Контролер који податке шаље у Слој модела
  3. Моделирајте податке о враћању у контролер
  4. Цонтроллер каже да ће Виев ажурирати своје стање новим подацима
  5. Погледајте ажурирање његовог стања

Аппле МВЦ

У иОС-у је Виев Цонтроллер спојен са УИКит-ом и приказом животног циклуса, тако да није чист МВЦ. Међутим, у дефиницији МВЦ не може се рећи да контролор не може знати специфичну имплементацију Виев или Модел. Његова главна сврха је одвојити одговорности слоја модела од слоја Виев како бисмо га могли поново користити и тестирати слој модела изолирано.

ВиевЦонтроллер садржи приказ и власник је модела. Проблем је што смо користили за писање кода контролера као и код за приказ у ВиевЦонтроллер.

МВЦ често ствара проблем Массиве Виев Цонтроллер, али то се догађа и постаје озбиљна ствар у апликацијама са довољно сложености.

Постоје неке методе које програмер може користити да би Виев Цонтроллер био више управљив. Неки примери:

  • Екстракција логике ВЦ-а за друге класе, попут приказа табеле, користи извор података и делегат за остале датотеке користећи образац дизајна делегата.
  • Направите јаснију поделу одговорности са саставом (нпр. Поделите ВЦ на контролере за децу).
  • Користите образац дизајна координатора да бисте уклонили одговорност за имплементацију навигацијске логике у ВЦ-у
  • Користите класу омота ДатаПресентер која енкапсулира логику и претвара модел података у излаз података који представљају податке представљене крајњем кориснику.

МВЦ вс МВП

Како видите дијаграм МВП-а је врло сличан МВЦ-у

МВЦ је био корак напријед, али и даље га је обиљежило одсуство или тишина о неким стварима.

У међувремену, светска мрежа је расла и многе су се ствари у заједници програмера развијале. На пример, програмери су почели да користе Ајак и учитавају само делове страница уместо целе ХТМЛ странице одједном.

У МВЦ-у мислим да не постоји ништа што би указивало на то да контролор не би требао знати специфичну имплементацију Виев-а (одсуства).

ХТМЛ је био део Виев Виев слоја и многи су случајеви били глупи. У неким случајевима, он прима догађаје само од корисника и приказује визуелни садржај ГУИ-ја.

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

Логика презентације је логика која контролише како УИ треба приказати и како елементи УИ међусобно делују. Пример је логика контроле када индикатор учитавања треба да почне да се приказује / анимира и када треба да престане да приказује / анимира.

У МВП-у и МВВМ-у би требао бити глупи курац без икакве логике или интелигенције, а у иОС-у би контролер приказа требао бити дио Виев Лаиер-а. Чињеница да је Виев глуп значи да чак и логика презентације остаје изван слоја Виев.

Један од проблема МВЦ-а је тај што није јасно где би логика презентације требало да остане. Он једноставно ћути о томе. Да ли би логика презентације требала бити у нивоу приказа или у слоју модела?

Ако је улога модела да пружа само „сирове“ податке, то значи да би код у приказу био:

Размотрите следећи пример: имамо корисника са именом и презименом. У приказу морамо да прикажемо корисничко име као „Презиме, име“ (нпр. „Флорес, Тиаго“).

Ако је улога модела да пружи „сирове“ податке, то значи да би код у приказу био:

нека фирстНаме = усерМодел.гетФирстНаме ()
нека ластНаме = усерМодел.гетЛастНаме ()
намеЛабел.тект = ластНаме + "," + прво име

Дакле, то значи да би одговорност била за управљање логиком корисничког сучеља. Али то онемогућава логику корисничког сучеља да тестира јединицу.

Други приступ је да модел изложи само оне податке које је потребно приказати, скривајући било коју пословну логику од погледа. Али тада завршимо с моделима који управљају и пословном и корисничком сучељем. Било би тестирање јединице, али тада модел завршава, имплицитно зависи од погледа.

нека име = корисникМодел.гетДисплаиНаме ()
намеЛабел.тект = име

МВП је јасан у томе и логика презентације остаје у слоју презентације. Ово повећава проверљивост слоја Пресентер. Сада је модел и слој презентатора лако тестирати.

Нормално у МВП имплементацијама, приказ је скривен иза сучеља / протокола и не би требало бити референци на УИКит у Пресентер-у.

Још једна ствар коју треба имати на уму су транзитивне зависности.

Ако контролер има пословни слој као зависност, а пословни слој има слој приступа подацима као зависност, тада контролер има транзитивну зависност за слој приступа подацима. Пошто МВП имплементације обично користе уговор (протокол) између свих слојева, он нема транзитивне зависности.

Различити слојеви се такође мењају из различитих разлога и различитим брзинама. Дакле, када промените слој, не желите да то изазове секундарне ефекте / проблеме на осталим слојевима.

Протоколи су стабилнији од класа. Протоколи немају детаље имплементације и са уговорима, тако да је могуће променити детаље имплементације слоја без утицаја на остале слојеве.

Дакле, уговори (протоколи) стварају раздвајање између слојева.

МВП вс МВВМ

МВВМ дијаграм

Једна од главних разлика између МВП-а и МВВМ-а је та што у МВП-у Пресентер комуницира с погледом путем интерфејса, а у МВВМ-у је поглед оријентисан на промене података и догађаја.

У МВП-у правимо ручно повезивање између Пресентер-а и Виев-а помоћу интерфејса / протокола.
У МВВМ-у правимо аутоматско везивање података користећи нешто попут РкСвифт, КВО или користимо механизам са генеричким захтевима и затварачима.

У МВВМ-у нам чак и није потребан уговор (нпр. Јава интерфејс / иОС протокол) између ВиевМодел-а и Виев-а јер обично комуницирамо преко Обсервер Десигн Паттерн.

МВП користи образац делегата зато што Пресентер Лаиер Делегатес наређује на Лаиер Виев, па мора знати нешто о приказу чак и ако је само потпис интерфејса / протокола. Замислите разлику између центра за обавјештења и делегата ТаблеВиев. Центру за обавештавање нису потребна сучеља за стварање комуникацијског канала, али ТаблеВиев Делегатес користи протокол који би класе требало имплементирати.

Размислите о логици презентације индикатора оптерећења. На МВП презентацији ради ВиевПротоцол.сховЛоадингИндицатор. У МВВМ-у може постојати својство исЛоадинг у ВиевМоделу. Слој Виев путем аутоматског везивања података открива када се ово својство мења и освежава. МВП је императивнији од МВВМ-а, јер Пресентер даје наређења.

МВВМ је више о променама података него директним налозима, а ми повезујемо измене података и прегледавамо ажурирања. Ако користимо РкСвифт и функционалну парадигму реактивног програмирања заједно са МВВМ, код смо учинили још мање императивним и декларативнијим.

МВВМ је лакши за тестирање од МВП-а, јер МВВМ користи образац дизајна посматрача који на различите начине преноси податке између компоненти.
Тако да можемо да тестирамо само гледањем у промене података само поређењем два објекта, а не креирањем исмеваних метода позива за тестирање комуникације између Виев-а и Пресентер-а.

ПС: Извршио сам неке измене у чланку због којих је пуно порастао, па је било потребно поделити га на три дела. Трећи део можете прочитати овде.

Други део се овде завршава. Све повратне информације су добродошле. Трећи део говориће о ВИПЕР-у, ВИП-у, реактивном програмирању, компромисима, ограничењима и контекстуалном смислу.

Хвала вам за читање! Ако вам се свидео овај чланак, пљескајте
тако да и други могу да је читају :)