MVP vs MVC vs MVVM vs VIPER. Ce este mai bun pentru dezvoltarea iOS?

La fel ca fiecare casă are un subsol solid, fiecare proiect software, are o arhitectură software pe care este construită și fiecare proiect are propria structură a aplicației. Tipurile de modele arhitecturale pot varia, dar există 4 cele mai frecvent utilizate - cele din întreaga lume IT critică continuu, dar continuă să folosească în același timp: MVC, MVP, MVVM și Viper (ultimul ca model de arhitectură iOS mai ales) . Compararea acestor tipare și alegerea unei potriviri mai bune pentru fiecare proiect scris de Swift vor fi descoperite în continuare în acest articol.

Urmărind ordinea cronologică a lucrurilor, odată ce au apărut primele modele de proiectare software, problemele obișnuite ale acestor modele de arhitectură de dezvoltare ios nu au întârziat să ajungă.

De exemplu, problema comunicării server-client - cum interacționează unul cu altul? Sau una diferită - problema separării logicii de afaceri a aplicației de logica aplicației; cum ar trebui să funcționeze acesta în ceea ce privește arhitectura aplicației? Datorită lor, diferite modele de design pentru diferite straturi de arhitectură au văzut lumea; cele mai cunoscute dintre ele sunt:

- Model de design Singleton.

Acest model permite aplicarea unei clase doar unui singur obiect și această opțiune este utilă atunci când o cantitate limitată de instanțe (sau o singură instanță) este aprobată de sistem.

- Model de design decorator.

Spre deosebire de singleton, acest model, (denumit alternativ Wrapper împreună cu modelul Adapter), permite adăugarea unui anumit comportament la un singur obiect (fie static, fie dinamic) și toate acestea, fără a afecta comportamentul altor obiecte. se împarte o clasă cu.

- Model de proiectare a podului.

În primul rând introdus de notorii Gang of Four - autorii cărții „Design Patterns”, acest model arhitectural „folosește încapsularea, agregarea și poate folosi moștenirea pentru a separa responsabilitățile în diferite clase. programarea devine foarte utilă, deoarece modificările aduse codului unui program pot fi făcute cu ușurință, cu cunoștințe minime anterioare despre program. [Sursa: Wiki]

Deși aceste tipare sunt destul de diferite, problemele comune ale scriitorilor de coduri au apărut cu fiecare dintre ele; de exemplu, cu „masivitatea” lui Singleton. Singleton este prea global, deoarece dependențele codului dvs. sunt ascunse profund în aplicația dvs., în loc să fie expuse în interfețe. Motiv pentru care în timpul procesului de dezvoltare a software-ului apar în mod constant noi modele.

Cele 4 modele cele mai utilizate sunt MVC, MVP, MVVM și VIPER (în principal pentru iOS).

Dezvoltate în aceeași ordine ca cele enumerate, toate au propriile avantaje și defecte, provocând numeroase dispute cu privire la locul de aplicare a fiecăruia. Acordarea unui pic mai multă atenție celor mai bune practici pe care le implementează ar putea clarifica puțin lucrurile.

Model MVC

Bunicul tuturor modelelor software, introdus pentru prima dată la începutul anilor 1970 de către un om de știință norvegian în informatică Trygve Reenskaug, Module - View - Controller, cunoscut pe scară largă ca MVC, este una dintre primele abordări de tipare ale programării orientate pe obiecte.

Partea Vizualizare este responsabilă pentru afișarea tuturor pentru utilizatorul sistemului (interfețele aplicației mobile sau web etc.). Modelul este în general responsabil pentru bazele de date, entitățile comerciale și restul datelor. La rândul său, Controller reglează activitatea Modelului, datele furnizate bazei de date, afișarea din baza de date menționată până la partea View și invers.

Oricât de universal ar fi modelul MVC, cei mai mari doi concurenți - Apple și Google au propriile lor modele reprezentând sistemul Model - View - Controller. Problema pe care o are sistemul Apple constă în conexiunea strânsă dintre părțile View și Controller, strânse aproape până la punctul de a avea View & Controller unite și lăsând partea Model separată.

În consecință, rezultă un proces de testare slab - numai modelul ar putea fi examinat, V&C (datorită conexiunii strânse pe care o au) nu poate fi testat deloc.

Conexiunea robustă între segmentele Controler și View s-a dovedit a fi cu adevărat „nesănătoasă” atunci când vine vorba de software, așa că un nou model a văzut lumea în curând.

Model MVP.

Mulți dintre noi am auzit această comandă rapidă în contextul produsului minim viabil, dar în ceea ce privește ingineria software înseamnă ceva diferit. Modelul Model View Presenter are câteva puncte cheie, formând o mare prăpastie între acesta și MVC:

Model MVP

• Vizualizarea este mai slab asociată cu modelul. Prezentatorul este responsabil pentru legarea Modelului de Vizualizare.

• Testarea mai ușoară a unității, deoarece interacțiunea cu vizualizarea se face printr-o interfață.

• De obicei Vizualizați la prezentator = harta unu la unu. Vizualizările complexe pot avea prezentatori multipli.

Model MVC

• Controlerele se bazează pe comportamente și pot fi partajate între vizualizări

• Poate fi responsabil pentru stabilirea vizualizării de afișat
  [Sursa: Infragistics]

În acest aranjament, funcțiile modelului rămân aceleași; Prezentatorul este responsabil pentru logica de afaceri respectiv. Partea V este cea de interes special - deoarece este împărțită în două părți View și View Controller, care sunt autorizate pentru interacțiune. Atunci când există o întrebare MVVM vs MVC, sistemul de acest tip rezolvă problema modurilor de vizualizare și controlor „dependență grea” care se obișnuiau cu modelul MVC.

Obstacolul testării este, de asemenea, rezolvat în acest caz, ca model, vizualizare cu interacțiunea cu utilizatorul și piese prezentator - toate acestea ar putea fi testate.
Inconvenientul încă existent este în partea lui Presenter - totuși mult prea masiv, dar ia în considerare toate logicele comerciale existente. Acesta este motivul pentru care a intrat în joc următorul act, numit ...

Modelul MVVM

Un model arhitectural software -View-ViewModel a fost creat în 2005 de John Gossman, unul dintre arhitecții Microsoft. Cele trei componente de bază ale modelului MVVM sunt, respectiv:
Modelul este „o implementare a modelului de domeniu al aplicației care include un model de date împreună cu logica de afaceri și de validare. Exemple de obiecte model includ depozite, obiecte de afaceri, obiecte de transfer de date (DTO), obiecte Plr Old CLR (POCO) și obiecte generate de entitate și proxy. ” [Sursa: Microsoft]

Vizualizarea este din nou tot ceea ce utilizatorul este capabil să vadă - aspectul, structura și aspectul a tot ce este pe ecran. Practic, în cadrul aplicației ar fi pagina aplicației. View primește și trimite actualizări numai la ViewModel, excluzând toate comunicările dintre această parte și Modelul în sine.

ViewModel ar trebui să fie un „lanț de interconectare” între componentele sistemului și modelul și funcția sa principală este de a gestiona logica vederii. De obicei, modelul de vizualizare interacționează cu modelul invocând metode în clasele de model. Modelul de vizualizare oferă apoi date din model într-o formă pe care vizualizarea o poate utiliza cu ușurință, așa cum afirmă Microsoft.

Principala diferență între MVC și iOS MVVM este că modelul de distribuție al MVVM este mai bun decât în ​​MVC listat anterior, dar în comparație cu MVP este, de asemenea, suprasolicitat masiv. Testarea este o chestiune de o importanță deosebită aici, deoarece, în timp ce scrieți în mod clar codul, nu puteți garanta că întregul proiect va funcționa corect - testele, pe baza notei luminoase, vă ajută să vă asigurați că va funcționa.

Evoluția următoarelor tipare arhitecturale a fost lansată recent și este acum cea mai nouă abordare arhitecturală software.

Arhitectura VIPER iOS

Căutând cea mai bună soluție arhitecturală de livrat, dezvoltatorii iOS din întreaga lume s-au lovit de așa-numita abordare „Arhitectură curată”, introdusă de Unchiul Bob pe Clean Coders - o platformă bine cunoscută care oferă sesiuni de instruire pentru profesioniștii din domeniul software-ului din întreaga lume.

Clean Architecture împarte structura logică a aplicației în mai multe niveluri de responsabilitate. La rândul său, această „separare” rezolvă problemele strânse de dependență și crește disponibilitatea testării la toate nivelurile.

VIPER pentru dezvoltarea iOS

VIPER este o realizare a Arhitecturii curate pentru aplicațiile construite pe iOS. Ca regulă comună pentru toate numele modelelor, este și un backronim, pentru View, Interactor, Presenter, Entity și Routing. Fiecare dintre părțile VIPER este responsabilă pentru un anumit element, în special:

1. Vizualizarea este responsabilă pentru oglindirea acțiunilor pe care le face utilizatorul cu o interfață

2. Responsabilitățile prezentatorului în cadrul modelului VIPER sunt destul de limitate - primește actualizările de la Entitate, dar nu îi trimite niciun fel de date;

3. Interactor este partea sistemului care corespunde de fapt cu entități. Această schemă funcționează în următoarea direcție: Presenter îl informează pe Interactor despre modificările din modelul View, apoi Interactor contactează partea Entity și, cu datele primite de la Entity Interactor, revine la Presenter, care comandă View pentru a o reflecta pentru un utilizator. Toate modelele de date, toate entitățile și toate site-urile web sunt conectate la partea Interactor.

4. Entitatea este alcătuită din obiecte care sunt controlate de Interactor (titluri, conținut etc.). Nu interacționează niciodată direct cu Presenter, doar prin partea I.

5. Rutare (sau Wireframe așa cum se numește uneori) este responsabilă pentru navigarea între toate ecranele și, în esență, pentru rutare. Wireframe controlează obiectele UIWindow, UINavigationController și așa mai departe.

În special în cadrul sistemului arhitectural iOS, totul este construit pe un cadru numit UIkit, care include toate componentele Apple MVC, dar fără o conexiune strânsă care obișnuia să înnebunească coderii înainte.

Modulul VIPER este la fel de benefic atunci când vine vorba de teste unitare, deoarece distribuția excelentă a modelului vă permite să testați toate funcționalitățile disponibile. Din multe puncte de vedere, aceasta a fost principala dificultate pe care dezvoltatorii s-au confruntat cu modelele software anterioare MVC, MVP și MVVM.

Pentru a încorona totul.

Toate aceste 4 modele de design software sunt adesea numite unul dintre cele mai bune modele de arhitectură pentru dezvoltarea iOS, chiar dacă toate sunt mai puțin ideale și cu siguranță nu sunt utilizate universal pentru fiecare proiect pe care îl veți dezvolta. În partea mohorâtă, iată o listă scurtă de probleme pe care le are fiecare model:

• MVC, MVP, MVVM - toți au această problemă de „conexiune strânsă”, ceea ce face ca introducerea actualizărilor în dezvoltare și testarea lor după aceea să fie o sarcină destul de dură de realizat.

• VIPER vs MVVM, MVC sau MVP , este considerat a fi un caz câștigător; deși, în ciuda flexibilității sale ridicate și a testabilității mari, are și multe nuanțe greu de generat.

Există o soluție 100% solidă? Nu chiar, dar pentru fiecare dintre proiectele dvs., unul dintre aceste 4 modele de aplicații iOS ar putea fi exact ceea ce aveți nevoie. Și dacă nu este, atunci ar fi un amestec de două. Sau chiar poate trei. Se spune că norocul favorizează îndrăznețul, deci de ce nu te joci cu îndrăzneală cu modelele de proiectare software?

Scris de Max Mashkov și Elina Bessarabova.