Modele de design pentru cacao MVC și MVVM

Modelele de proiectare fac codul aplicației mai modular și iertător atunci când vine vorba de corecții și modificări ale erorilor. În acest articol, veți învăța despre MVC (Model-View-Controller) și modelele de design MVVM (Model-View-ViewModel).

Deși modelele de design (cunoscute și ca modele arhitecturale) sunt esențiale pentru dezvoltarea aplicațiilor scalabile Cocoa Touch, există o mulțime de controverse în jurul căreia modelul arhitectural este de fapt cel mai bun pentru utilizarea în aplicația dvs.. 

Verificați aceste postări recente de către Bart Jacobs pe MVC și MVVM pentru mai multe perspective asupra acestor modele de design și a alegerii dintre ele.

• 

  De ce MVC nu ar fi cel mai bun model pentru aplicațiile pe bază de cacao

  Model-View-Controller (MVC) este un model general de dezvoltare software. Aflați ce este MVC și de ce este posibil să nu fie cea mai bună soluție pentru dezvoltatorii de cacao.
• 

  Puneți controlorii de vedere pe o dietă cu MVVM

  Aflați despre o alternativă la modelul MVC: Model-View-ViewModel. Vă voi arăta cum MVVM poate rezolva unele dintre deficiențele Model-View-Controller.

Colectarea de obiecte ale unui anumit model [arhitectural] într-o aplicație este uneori menționată ca un strat - de exemplu, stratul de model. - Măr

Fără alte detalii, să aruncăm o privire asupra câtorva modele de design pe care le puteți utiliza în următoarea aplicație.

MVC (Model-View-Controller)

Acesta este modelul cel mai frecvent utilizat în dezvoltarea Cocoa Touch, și este, de asemenea, favoritul meu personal. Acest model de design îți sortează în mod eficient și eficient codul în trei categorii (sau straturi): modelul, vizualizarea și controlerul.

Cum funcționează și de ce ar trebui să o folosesc?

Cu acest model de design, puteți efectua modificări la un singur strat fără a afecta celelalte straturi ale modelului. De exemplu, dacă trebuie să schimbați baza de date, tocmai ați elimina modelul și îl înlocuiți fără a trebui să editați vizualizarea sau controlerul. Sau dacă doriți să schimbați modul în care arată o vizualizare, nu trebuie să vă faceți griji în legătură cu codul bazei de date. Aceasta se numește "separarea preocupărilor" și face codul dvs. mai ușor de depanat, de întreținut și de reutilizat.

În plus, acesta este modelul de design care este recomandat de Apple în sine, și este o normă în comunitatea de dezvoltare iOS. Dacă tocmai începeți, vă recomand să vă lipiți de acest model. Puteți încerca diferite modele de design mai târziu în cariera dvs. de dezvoltare a cacao.

Straturi și responsabilități

Să aruncăm o privire mai atentă la diferitele straturi din acest model și pentru ce este responsabil fiecare dintre ele. Iată o diagramă rapidă a interacțiunilor dintre straturi:

Modelul de proiectare MVC separă fiecare parte a codului dvs. într-una din cele trei părți: modelul, vizualizarea și controlerul. 

• Model: Acest strat este numai responsabil pentru datele și forma sa, așa cum apare în aplicația dvs. Stratul Controller poate modifica datele aplicației prin notificarea modelului. Modelul nu este responsabil pentru orice altceva, inclusiv modul în care datele sunt prezentate utilizatorului sau care sau ce folosește datele.
• Vedere: Vizualizarea este responsabilă pentru reprezentarea datelor-numai modul în care utilizatorul vede și interacționează cu datele. Acestea pot include celule reutilizabile, tabele și alte elemente ale interfeței utilizator care nu știu nimic despre date sau modul în care sunt tratate. Datele sunt furnizate elementelor de vizualizare de către controlor.
  
• Controlor: Controlerul este steaua spectacolului. Acesta aduce datele din model și apoi o transmite către vizualizarea care trebuie afișată utilizatorului. Acesta este singurul strat dintre Model și Vedere, care poate cauza unele probleme, pe care le vom examina mai târziu în acest articol. Controlorul este de obicei implementat în ViewController.swift,și este responsabil pentru ascultarea de intrare și schimbarea modelului după cum este necesar.

Un lucru pe care trebuie să-l țineți minte este că nu ar trebui să vă grăbiți prea multe responsabilități în oricare dintre aceste straturi, deoarece acest lucru ar învinge scopul de a avea un model de design!

De asemenea, dacă nu țineți conexiunile între straturi curat și clar, veți termina cu o aplicație dezordonată și nefolositoare, în ciuda faptului că utilizați modelul de design MVC! În special, asigurați-vă că nu face permiteți vizualizarea și modelul să comunice direct. Aceste interacțiuni trebuie să se realizeze numai prin controler.

MVVM (Model-View-ViewModel)

Cu toate că modelul de design-View-Controller este destul de comun și ar trebui să funcționeze în majoritatea cazurilor, acesta are propriul set de provocări și dezavantaje. Din acest motiv, avem un alt model de design numit MVVM, care reprezintă Model-View-ViewModel.

MVC este minunat, deci de ce am nevoie de MVVM?

Există o problemă majoră pe care ar trebui să o cunoști. După cum ați văzut în secțiunea anterioară, stratul Controller este singurul strat dintre vizualizare și model, deci nu este surprinzător faptul că oamenii abuzează acest strat și îi dau repede prea multe lucruri de făcut. Acest lucru ar putea părea ca cel mai simplu lucru de făcut la acea dată, deoarece evită schimbarea celorlalte straturi, dar în cele din urmă duce la un controler umflat și un cod greu de întreținut.

Acest lucru a determinat ca MVC să primească porecla capricioasă "Massive-View-Controller" în unele cercuri.

Modelul arhitectural MVVM, care a fost împrumutat de dezvoltatorii de cocoa de la Microsoft, poate ajuta la combaterea acestei probleme a controlorilor de vizualizare masivi. Deși nu este atât de comun în dezvoltarea iOS ca MVC, este din ce în ce mai mult folosit pentru a compensa deficiențele MVC.

Straturi și responsabilități

Să aruncăm o privire asupra diferitelor straturi și a responsabilităților lor în MVVM. (Probabil ar trebui să rețineți că în comunitatea de cacao nu există orientări formale privind utilizarea acestor straturi.) 

Iată o diagramă rapidă care demonstrează straturile acestui model arhitectural și legăturile lor una cu cealaltă.

Dacă vă gândiți la asta, veți vedea că, deși vederile și controlorii sunt straturi separate în modelul de design MVC, ele sunt foarte strâns legate. Astfel, în MVVM, luăm pur și simplu Vizualizarea și Controlorul și le combinăm într-un singur strat. 

Să comparăm fiecare strat cu omologul său în modelul MVC. 

• (Vizualizare) Controler: Acest strat, de obicei cunoscut doar sub numele de View, este strâns legat de controler. Atât de mult încât nu sunt nici măcar separate în straturi diferite! Privelistea numai comunică cu Controlerul, dar Controlorul comunică cu ViewModel și Vizualizare. Vizualizarea și controlerul execută aceleași sarcini ca și în MVC, dar diferența este că unele sarcini care au fost date controlerului (în MVC) sunt acum tratate de un strat intermediar, ViewModel, pentru a preveni utilizarea greșită a controlerului. Vizualizarea gestionează în continuare afișarea datelor către utilizator, iar controlerul răspunde la evenimentele utilizatorilor și comunică cu restul straturilor modelului.
• ViewModel: Acest strat nu conține, de fapt, nici un fel de "vederi" pe cont propriu, ci manipulează logica în spatele afișării vederilor - de obicei numită logică de prezentare. Aceasta include crearea de fișiere personalizate de formatare și procesare pentru a fi afișate, precum și de fapt, crunching numere care urmează să fie afișate pentru utilizator pe baza datelor din stratul Model. 
  
• Model: Modelul nu diferă foarte mult de stratul Model din modelul MVC. După cum am văzut înainte, modelul numai gestionează datele și face modificări acestor date dacă primește actualizări din stratul ViewModel. face nu știți despre cine utilizează datele, despre ce fac cu el sau despre modul în care utilizatorul vede datele.

După cum ați văzut anterior, nu trebuie să amestecați responsabilitățile niciunuia dintre aceste straturi, deoarece acest lucru poate determina codul aplicației dvs. să fie spiralat în complexitate, făcând ca utilizarea oricăror modele de design redundante.

Concluzie

Sper că v-ați bucurat să aflați mai multe despre aceste modele fundamentale de design pentru iOS. Sperăm că ați câștigat o mai bună înțelegere a modelelor de design MVC și MVVM și sunteți suficient de încrezători să le folosiți în aplicațiile viitoare. 

Desigur, modelul arhitectural pe care îl utilizați pentru aplicația dvs. este total dependent de dvs. și depinde de tipul de aplicație pe care încercați să o dezvoltați. Cu toate acestea, dacă sunteți nou în dezvoltarea iOS, eu tot recomandăm să vă lipiți de modelul de design MVC deoarece este încă cea mai importantă din dezvoltarea cacao.

În timp ce sunteți aici, asigurați-vă că ați verificat câteva dintre celelalte tutoriale și articole despre Envato Tuts+!