Diferența dintre MVVM și MVP

Scopul dezvoltării de software este de a construi soluții care să abordeze nevoile și problemele pentru utilizatori și companii. Pentru a realiza acest lucru, diferite tehnologii și modele de arhitectură cum ar fi Model-View-ViewModel (MVVM) și Vizualizare-prezentare model (MVP) sunt folosite.

Ca și în cazul a ceea ce este fabricat, primul pas este etapa de planificare și proiectare. Procesul de proiectare a software-ului poate fi o specificație bazată pe un set de instrumente tehnologice preferate și poate cuprinde întreaga activitate de la concepție la planificare la implementare la actualizări și modificări.

Acesta acoperă designul arhitectural de nivel inferior și de nivel înalt, bazat pe modele de arhitectură selectate și găsește soluții reutilizabile utilizând modele de design.

Structura aplicației software

Arhitectura software definește o structură a aplicației care satisface cerințele tehnice, operaționale și de utilizare și se referă la modul în care este organizat și gestionat codul.

Deciderea unei arhitecturi a unei aplicații software este esențială, deoarece nu este o parte ușor schimbabilă a unei aplicații deja dezvoltate; prin urmare, modelul arhitectural trebuie stabilit înainte de începerea oricărei programări.

Modelele arhitecturale sunt oarecum diferite de modelele de design, deoarece domeniul lor de aplicare este mult mai larg, abordând mai multe aspecte tehnice, cum ar fi performanța și limitările hardware-ului, disponibilitatea ridicată. Exemple de modele de arhitectură diferite sunt MVC, MVVM și MVP.

Pe de altă parte, modelele de design sunt cele mai bune practici formalizate care facilitează dezvoltarea orientată spre obiecte refolosibile și sunt mai ușor de întreținut și de schimbat decât arhitectura unei aplicații. 

Modele de arhitectură

Controller vizualizare model (MVC) a fost unul dintre primele modele arhitecturale dezvoltate pentru aplicații web, câștigând popularitate de la mijlocul până la sfârșitul anilor nouăzeci, în special cu comunitatea Java.

Cadrele mai noi, cum ar fi Django pentru Python și Rails (Ruby on Rails), au un accent puternic pe implementarea rapidă, motiv pentru care MVC ocupă cota de piață ca atracție majoră în modelele arhitecturale.

În mod tradițional, dezvoltarea interfeței cu utilizatorul conținea o mulțime de coduri pentru a gestiona logica complicată, astfel încât modelele de arhitectură au fost proiectate pentru a reduce codul la nivelul interfeței utilizator (UI), făcându-l mai "curat" și ușor de gestionat.

Deci, cu modelul MVC, o aplicație web este compusă din

• Model (date)
• Vedere (interfață pentru vizualizarea și manipularea datelor)
• Controlor (operațiunile și acțiunile efectuate asupra datelor)

Model gestionează datele și logica de afaceri și există Nu dependențele dintre Model si Controlor sau Vedere.

Vedere prezintă datele utilizatorului în formatul acceptat și aspectul necesar și când Controlor primește cereri de utilizator (pentru a prelua date), solicită resursele necesare pentru completarea cererii.

Să aplicăm acest model pentru construirea unui magazin online de cărți.

Utilizatorii pot căuta, vizualiza, înregistra și cumpăra cărți, precum și gestionează profilurile și listele de cărți. Când un utilizator dă clic pe categoria SCI-FI, toate cărțile asociate ar trebui afișate ca fiind disponibile.

controlerele gestionați acțiunile care gestionează cărțile (listă, adăugați, vizualizați, etc.). Pot exista mai multe controlerele cu una principală Controlor "direcționarea traficului".

Pentru acest exemplu, Controlor este numit controller_books.php și Model (de exemplu, model_books.php) gestionează datele și logica referitoare la cărți.

În cele din urmă, diferite Vizualizări va fi necesar, cum ar fi adăugarea cărților la căruța online sau vizualizarea detaliilor cărților cu imagini și recenzii.

controller_books.php primește acțiunea (solicitarea utilizatorului) din partea principală Controlor (de exemplu. index.php). controller_books.php analizează solicitarea și sună model_books.php (datele) pentru a returna lista de cărți SCI-FI.

Responsabilitatea Model este de a furniza aceste informații, folosind orice logică care a fost aplicată (folosind filtrele de căutare). Controlor apoi ia informația și o transmite către partea relevantă Vedere (vizualizare de căutare, vizualizare de imprimare, vizualizare detaliu etc) și informațiile sunt prezentate (prin Vedere) către utilizatorul care a inițiat solicitarea.

Acestea sunt fundamentele modelului MVC, care a modificat variațiile de reproducere a tiparelor de arhitectură, cum ar fi Model-View-Presenter (MVP), Model-View-ViewModel (MVVM), Controller de vizualizare ierarhică (HMVC) și Model-View-Adapter (MVA), etc..

Modelul MVP

Vizualizare-prezentare model (MVP)

Modelul MVP a fost în jur de ceva timp și este o variantă a MVC. Acesta a fost conceput special pentru automatizarea testelor, unde obiectivul a fost de a crește cantitatea de cod care poate fi testată prin automatizare, iar modelul abordează unele probleme cu stratul de prezentare, izolând logica de afaceri de interfața de utilizare.

Ecranul este vizualizarea, datele pe care le afișează este modelul, iar prezentatorul leagă cele două împreună.

MVP cuprinde următoarele componente cu responsabilități separate:

• Model (definește datele care vor fi afișate)
• Vedere (afișează datele din model și cerințele utilizatorilor către prezentator).
• Prezentator (interacționează între Vizualizare și Model și leagă-le împreună)

Vedere (o pagină Web) afișează și gestionează comenzile de pagină prin redirecționarea evenimentelor (cereri de utilizator) către Prezentator care au fost inițiate în Vedere.

Prezentator răspunde la aceste evenimente prin citirea și actualizarea Model pentru a schimba Vedere și, prin urmare, prezentatorului responsabilitatea este de a le lega Model și Vedere.

După ce te uiți MVC și MVP modele comune, ambele au responsabilități separate pentru fiecare componentă și ele promovează separarea dintre Vedere (UI) și Model (date). Diferențele semnificative între aceste modele sunt mai evidente în modul în care modelele sunt implementate.

MVP poate fi un model complex de implementat pentru soluții avansate, dar cu siguranță are mari beneficii dacă este implementat ca o soluție bine concepută, deși nu poate fi neapărat alegerea potrivită pentru soluții simple.

Modelul MVVM

Model-View-ViewModel (MVVM)

MVVM model a fost proiectat special pentru platformele Windows Presentation Foundation (WPF) și Microsoft Silverlight și poate fi utilizat pe toate XAML [i] platforme.

WPF este un sistem Microsoft care face interfețe utilizator în programele bazate pe Windows și a fost lansat pentru prima oară în .NET Framework 3.0.

MVVM a fost rafinat de la MVC și în acest model, Vedere este activ cu comportamentele, evenimentele și legarea datelor, și Vedere se sincronizează cu ViewModel (care permite separarea prezentării și expune metodele și comenzile de a gestiona și manipula Model.

MVVM cuprinde trei componente principale:

• Model (reprezintă datele cu validare și logica de afaceri)
• Vedere (Vederea este responsabilă pentru definirea structurii, a aspectului și a aspectului a ceea ce văd utilizatorul pe ecran. În mod ideal, vizualizarea este definită doar cu XAML, cu un cod limitat în spatele căruia nu există logică de afaceri, obligatorie între Vedere și ViewModel pentru a afișa sincronizarea Modelului și ViewModel cu vizualizarea)
• ViewModel (separă vizualizarea de la model și expune metodele și comenzile pentru a manipula datele (Model).

Vedere primește date de la ViewModel (prin legarea de date și metode), și în timpul execuției, Vedere se va schimba atunci când răspundeți la evenimentele din ViewModel.

ViewModel mediază între Vedere și Model și manipulează Vedere logică. Interacționează cu Model - preluarea datelor din Model și prezentarea acestuia către Vedere a afișa.

Aceste componente sunt decuplate una de cealaltă, permițând o mai mare flexibilitate pentru a lucra în mod independent, pentru a izola unitățile de testare și a le schimba, fără a afecta niciun alt component.

Această structură permite Model și alte componente pentru a evolua independent, permițând dezvoltatorilor să lucreze simultan asupra diferitelor aspecte ale soluției. De exemplu, în cazul în care designerii lucrează la Vedere, acestea generează pur și simplu eșantioane de date fără a avea nevoie de acces la celelalte componente. Acest lucru facilitează reproiectarea ușoară a interfeței utilizator ca Vedere este implementat în XAML.

Așa cum am menționat anterior cu MVP, soluții simple nu ar avea nevoie de arhitectură și modele de design, cum ar fi "Hello World!" este prea de bază pentru a urma orice tipar; cu toate acestea, pe măsură ce sunt introduse mai multe caracteristici, funcții și componente, complexitatea aplicației crește, la fel și cantitatea de cod care trebuie gestionată.

În concluzie

De la începutul dezvoltării interfeței cu utilizatorul, modelele de design devin din ce în ce mai populare pentru a ușura procesul de dezvoltare, aplicațiile mai scalabile și facilitează testarea mai ușoară.

Diferența ilustrată între modelele MVP și MVVM:

• În ambele MVP și MVVM, Vedere este punctul de intrare la cerere
• În MVP, există o mapare unu-la-unu între Vedere și Prezentator, unde in MVVM, relația este una-la-multe între Vedere și ViewModel.
• MVP este folosit în principal pentru aplicațiile Windows Forms și Windows Phone și Windows MVVM este proiectat pentru Silverlight, WPF, Knockout / AngularJS, etc.