Kā izvēlēties piemērotu iOS arhitektūru (2. daļa)

MVC, MVP, MVVM, VIPER vai VIP

Ar pirmo daļu varat iepazīties šeit.

Galvenās iOS arhitektūras

Īss pārskats.

MVC

MVC slāņi ir šādi:

M: biznesa loģika, tīkla slānis un datu piekļuves slānis

V: UI slānis (UIKit lietas, scenāriji, Xibs)

C: koordinē starpniecību starp modeli un skatu.

Lai saprastu MVC, mums ir jāsaprot konteksts, kurā tas tika izgudrots. MVC tika izgudrots vecajās Web izstrādes dienās, kur Views nebija valsts. Vecajos laikos katru reizi, kad mums ir vajadzīgas vizuālas izmaiņas vietnē, pārlūks atkārtoti ielādē visu HTML. Tajā laikā nebija koncepcijas par skata stāvokļa uzturēšanu un saglabāšanu.

Piemēram, bija daži izstrādātāji, kas sajaucās tajā pašā HTML failā, PHP un piekļuvei datu bāzei. Tātad galvenā MVC motivācija bija atdalīt skatu slāni no modeļa slāņa. Tas palielināja modeļa slāņa pārbaudāmību. Domājams, ka MVC slānī Skats un Modelis nevajadzētu neko zināt. Lai tas būtu iespējams, tika izgudrots starpniekslānis ar nosaukumu Kontrolieris. Tika piemērota SRP.

MVC cikla piemērs:

  1. Tiek aktivizēta lietotāja darbība / notikums skata slānī (piem., Refresh Action) un šī darbība tiek paziņota kontrolierim
  2. Kontrolieris, kurš pieprasa datus modeļa slānim
  3. Modelējiet atgrieztos datus kontrolierim
  4. Kontrolieris apgalvo, ka skatam atjaunina savu stāvokli ar jaunajiem datiem
  5. Skatīt atjaunināt viņa stāvokli

Apple MVC

IOS operētājsistēmā View Controller ir pievienots UIKit un dzīves cikla skats, tāpēc tas nav tīrs MVC. Tomēr MVC definīcijā nekas neliecina, ka kontrolieris nevar zināt konkrētu skata vai modeļa ieviešanu. Viņa galvenais mērķis ir nodalīt modeļa slāni no skata slāņa, lai mēs varētu to atkārtoti izmantot un pārbaudīt modeļa slāni izolēti.

ViewController satur skatu un tam pieder modelis. Problēma ir tā, ka mēs esam pieraduši kontroliera kodu, kā arī skata kodu rakstīt ViewController.

MVC bieži rada saucamo masīvā skata kontroliera problēmu, bet tas notiek tikai un kļūst par nopietnu lietu lietotnēs ar pietiekami sarežģītību.

Ir dažas metodes, kuras izstrādātājs var izmantot, lai skatītāja kontrolieri padarītu pārvaldāmāku. Daži piemēri:

  • VC loģikas iegūšana citām klasēm, piemēram, tabulas skata metožu datu avotam, un deleģēšana citiem failiem, izmantojot deleģēto modeli.
  • Izveidojiet skaidrāku pienākumu sadalījumu ar sastāvu (piemēram, sadaliet RK bērnu skatīšanās kontrolieros).
  • Izmantojiet koordinatora dizaina modeli, lai noņemtu atbildību par navigācijas loģikas ieviešanu RK
  • Izmantojiet DataPresenter iesaiņojuma klasi, kas iekapsulē loģiku un pārveido datu modeli datu izvadē, kas atspoguļo datus, kas tiek uzrādīti gala lietotājam.

MVC vs MVP

Tas, kā jūs varat redzēt MVP shēmu, ir ļoti līdzīgs MVC

MVC bija solis uz priekšu, taču to joprojām iezīmēja prombūtne vai klusums par dažām lietām.

Tikmēr pieauga globālais tīmeklis, un attīstītāju sabiedrībā attīstījās daudzas lietas. Piemēram, programmētāji sāka lietot Ajax un ielādēt tikai lapu daļas, nevis visu HTML lapu uzreiz.

MVC, manuprāt, nekas neliecina, ka kontrolierim nebūtu jāzina konkrētā skata (neesamības) ieviešana.

HTML bija daļa no slāņa Skatīt, un daudzi gadījumi bija mēmi kā izdrāzt. Dažos gadījumos tas tikai saņem notikumus no lietotāja un parāda GUI vizuālo saturu.

Tā kā tīmekļa lapu daļas sāka ielādēt daļās, šī segmentēšana veica skata stāvokļa saglabāšanas un lielāku nepieciešamību pēc prezentācijas loģikas atbildības nodalīšanas.

Prezentācijas loģika ir loģika, kas kontrolē, kā jāparāda lietotāja saskarne un kā lietotāja interfeisa elementi mijiedarbojas. Piemērs ir vadības loģika, kad iekraušanas indikators jāsāk rādīt / animēt un kad tas jāpārtrauc rādīt / animēt.

MVP un MVVM skatu slānim vajadzētu būt mēmam kā izdrāzt, bez tajā esošas loģikas vai intelekta, un iOS ierīcē skata kontrolierim vajadzētu būt skata slāņa daļai. Tas, ka skats ir mēms, nozīmē, ka pat prezentācijas loģika paliek ārpus skata slāņa.

Viena no MVC problēmām ir tā, ka nav skaidrs, kur jāpaliek prezentācijas loģikai. Viņš par to vienkārši klusē. Vai prezentācijas loģikai vajadzētu būt skata slānī vai modeļa slānī?

Ja modeļa uzdevums ir vienkārši sniegt neapstrādātus datus, tas nozīmē, ka skatā redzamais kods ir:

Apsveriet šo piemēru: mums ir lietotājs ar vārdu un uzvārdu. Skatā mums lietotājvārds jāparāda kā “Uzvārds, vārds” (piemēram, “Flores, Tiago”).

Ja modeļa uzdevums ir sniegt neapstrādātus datus, tas nozīmē, ka skatā redzamais kods ir:

let firstName = userModel.getFirstName ()
let lastName = userModel.getLastName ()
nameLabel.text = lastName + “,“ + firstName

Tas nozīmē, ka par lietotāja interfeisa loģikas pārvaldīšanu ir atbildīgs skats. Bet tas padara UI loģiku neiespējamu vienības pārbaudē.

Otra pieeja ir panākt, lai modelis pakļauj tikai tos datus, kas jāparāda, no skata paslēpjot jebkādu biznesa loģiku. Bet pēc tam mēs nonākam pie modeļiem, kas darbojas gan biznesa, gan UI loģikā. Tas būtu pārbaudāms ar vienību, bet pēc tam modelis nonāk, netieši atkarīgs no skata.

let name = userModel.getDisplayName ()
nameLabel.text = nosaukums

MVP par to ir skaidrs, un prezentācijas loģika paliek Presenter Layer. Tas palielina Presenter slāņa pārbaudāmību. Tagad modeļa un prezentētāja slānis ir viegli pārbaudāms.

Parasti MVP implementācijās skats ir paslēpts aiz interfeisa / protokola, un Presenter nedrīkst būt atsauces uz UIKit.

Vēl viena lieta, kas jāpatur prātā, ir pārejošās atkarības.

Ja kontrolierim ir biznesa slānis kā atkarība un biznesa slānim ir datu piekļuves slānis kā atkarībai, tad kontrolierim ir pārejas atkarība no datu piekļuves slāņa. Tā kā MVP implementācijas parasti izmanto līgumu (protokolu) starp visiem slāņiem, tam nav tranzīta atkarību.

Dažādie slāņi mainās arī dažādu iemeslu dēļ un ar atšķirīgu ātrumu. Tātad, mainot slāni, jūs nevēlaties, lai tas radītu sekundārus efektus / problēmas pārējos slāņos.

Protokoli ir stabilāki nekā klases. Protokolos nav detalizētas informācijas par ieviešanu un ar līgumiem, tāpēc ir iespējams mainīt slāņa ieviešanas informāciju, neietekmējot citus slāņus.

Tātad līgumi (protokoli) izveido atsaistīšanu starp slāņiem.

MVP vs MVVM

MVVM shēma

Viena no galvenajām atšķirībām starp MVP un MVVM ir tā, ka MVP prezentētājs sazinās ar skatu caur saskarnēm, un MVVM skats ir orientēts uz datu un notikumu izmaiņām.

MVP mēs veicam manuālu iesiešanu starp Presenter un View, izmantojot interfeisus / protokolus.
MVVM mēs veicam automātisku datu iesiešanu, izmantojot kaut ko līdzīgu RxSwift, KVO, vai arī izmantojam mehānismu ar ģenēriskām zālēm un slēgumiem.

MVVM mums pat nav nepieciešams līgums (piemēram: java interfeiss / iOS protokols) starp ViewModel un View, jo mēs parasti sazināmies caur Observer Design Pattern.

MVP izmanto deleģēšanas modeli, jo Presenter Layer deleģē skata slāni, tāpēc tam kaut kas jāzina par skatu, pat ja tas ir tikai interfeisa / protokola paraksts. Padomājiet par atšķirību starp Paziņojumu centru un TableView delegāti. Paziņojumu centram nav vajadzīgas saskarnes, lai izveidotu sakaru kanālu, bet TableView Delegates izmanto protokolu, kas klasēm jāievieš.

Padomājiet par iekraušanas indikatora noformējuma loģiku. MVP programmā vadītājs veic ViewProtocol.showLoadingIndicator. MVVM ViewModel var būt īpašums isLoading. Slānis Skatīt, izmantojot automātisku datu iesiešanu, nosaka, kad mainās šis īpašums un atjaunojas. MVP ir vairāk obligāti nekā MVVM, jo Presenter dod rīkojumus.

MVVM vairāk attiecas uz datu izmaiņām nekā tiešajiem pasūtījumiem, un mēs veicam asociācijas starp datu izmaiņām un skata atjauninājumiem. Ja RxSwift un funkcionālās reaktīvās programmēšanas paradigmu izmantojam kopā ar MVVM, mēs esam padarījuši kodu vēl mazāk obligātu un deklaratīvāku.

MVVM ir vieglāk pārbaudīt nekā MVP, jo MVVM izmanto novērotāju dizaina modeli, kas pārsūta datus starp komponentiem atsaistītā veidā.
Tātad mēs varam pārbaudīt, tikai aplūkojot datu izmaiņas, salīdzinot tikai divus objektus, nevis veidojot izsmieklu metodes izsaukumus, lai pārbaudītu saziņu starp skatu un prezentētāju.

PS: Es izdarīju dažus rakstu atjauninājumus, kas lika tam daudz augt, tāpēc bija nepieciešams to sadalīt trīs daļās. Trešo daļu var izlasīt šeit.

Otrā daļa šeit beidzas. Visas atsauksmes ir laipni gaidītas. Trešajā daļā tiks runāts par VIPER, VIP, Reaktīvo programmēšanu, kompromisiem, ierobežojumiem un konteksta izpratni.

Paldies par lasīšanu! Ja jums patika šis raksts, lūdzu, aplaudējiet
lai arī citi cilvēki to varētu izlasīt :)