MVC design pattern

Dacă ești web developer, s-ar putea să auzi destul de des acronimul ‘MVC’ și să nu știi exact ce înseamnă.

Dar sunt sigur că ai interacționat cel puțin o dată cu o aplicație ce folosea MVC, dar nu ți-ai dat seama.

Hai să vedem întâi ce înseamnă, pentru că numele nu ne spune mai nimic în mod direct.

Ei bine, MVC vine de la Model-View-Controller și e un “design pattern” sau șablon de design arhitectural dacă vrei, folosit în dezvoltarea aplicațiilor web moderne.

Cele 3 cuvinte din denumire sunt cele 3 elemente care intră în componența acestui șablon: Model, View și Controller.

Cele 3 componente: Model, View, Controller

Hai să vedem pe scurt care este rolul celor 3 componente definite de design pattern-ul MVC.

Model

Rolul modelului e acela de a încapsula datele transmise de la controller la view. De asemenea modelul este folosit la validarea datelor transmise și definirea acțiunilor pe care un utilizator le poate face în anumite situații.

Modelul este folosit pentru a transmite atât date de la controller la view, cât și de la view la controller.

E folosit ca un vehicul de transport în ambele sensuri, dacă vrei.

View

View-ul e componenta care definește modul cum arată o pagină web. Deci va include toate elementele HTML necesare, codul CSS pentru stilizarea elementelor respective, cât și ceva cod de JavaScript dacă există și logică definită direct în pagină (de exemplu pentru validarea datelor introduse).

În general view-ul nu va defini niciun fel de reguli care vor dicta logica sau fluxul datelor în aplicație ci doar simple validări sau elemente de dinamică.

De exemplu, afișarea unui mesaj informativ atunci când utilizatorul derulează pagina până într-un anumit punct, sau dă click pe un element anume.

View-ul va folosi datele ce vin în model pentru a le afișa utilizatorului pe ecran și le va transmite înapoi la model dacă utilizatorul dorește să execute o acțiune de actualizare a datelor respective, de exemplu.

Controller

Controller-ul e componenta care orchestrează toată această interacțiune, fiind și elementul de legătură dintre model și view.

Controller-ul are la îndemână serviciile necesare pentru a aduce date din baza de date, în funcție de context, date pe care în general le folosește pentru a popula modelul și a-l transmite la view.

Controller-ul pune astfel la dispoziția utilizatorului datele pe care acesta poate să opereze.

În sens invers, în momentul în care utilizatorul dorește să facă o acțiune în view-ul pe care controller-ul îl administrează, acțiunea va ajunge înapoi la controller-ul sursă cu același model pe care l-a trimis inițial, dar cu datele ajustate în funcție de schimbările făcute de utilizator în view.

Controller-ul decide ce acțiuni să execute mai departe în funcție de datele primite și contextul dat.

Care este scopul MVC

Acum că ai înțeles care sunt cele 3 componente și rolul lor, poate te întrebi care a fost scopul acestei segregări.

Problema pe care MVC design pattern încearcă să o rezolve e decuplarea datelor, comportamentului și interfeței grafice ale unei aplicații web în componente individuale.

De ce ai vrea să faci asta poate te întrebi.

Ei bine, în software engineering, spargerea unui sistem software în componente de genul ăsta aduce în principal avantajul reutilizării acestor componente în mai multe situații sau părți ale aplicației, reducând în final cantitatea de cod scrisă.

Uite un exemplu: într-o aplicație MVC, de multe ori pagina folosită drept “formular de înregistrare” a oricărui tip de entitate din baza de date (a unui produs, să spunem), e refolosită total sau parțial și la acțiunea de editare, pentru că ai avea nevoie, în principiu, de același set de câmpuri de introducere de date și butoane.

Desigur, cu anumite particularități, dar s-ar putea ca modul în care arată pagina în ambele cazuri să fie absolut identice.

De asemenea, un mare avantaj este că fiecare componentă poate evolua în mod independent, fără să le afecteze pe celelalte, iar lucrul ăsta face ca mentenanța aplicației să se facă mult mai ușor în viitor.

Dezavantajele folosirii MVC

Problema cea mai mare cu acest design pattern (sau “șablon” dacă vrei) e complexitatea.

Dacă nu ai mai lucrat cu aplicație ce folosește MVC, s-ar putea ca la prima vedere să fii puțin intimidat de faptul că modificările aduse uneia dintre cele 3 componente nu se propagă și la celelalte.

Și asta nu e doar atât, trebuie să înțelegi foarte bine rolul fiecărei componente și cum ar trebui să interacționeze cu celelalte pentru a nu le amesteca rolurile.

E foarte ușor să adaugi direct în view logică pe care ar trebui să o execute controller-ul, de exemplu, dar asta nu va face decât să te încurce și să complice lucrurile pe viitor.

Mai există și alte șabloane care încearcă să rezolve aceleași probleme ca și MVC, dar în moduri diferite, precum: MVVM (Model-View-ViewModel) sau MVP (Model-View-Presenter), despre acestea cu altă ocazie.

Când ar trebui să folosești MVC

MVC e mai potrivit în general pentru aplicații mari, enterprise, acolo unde sunt tratate cazuri și nevoi complexe.

Nu înțelege greșit, poți să-l folosești și la aplicații mici și foarte mici, dar introduce complexitate inutilă și s-ar putea mai mult să te încurce decât să te ajute.

Dacă vrei să înveți cum să faci o aplicație folosind șablonul MVC de la zero îți recomand C# Masterclass. ASP .NET e o tehnologie ce folosește limbajul de programare C# prin care poți dezvolta aplicații full-stack ce folosesc design pattern-ul MVC și despre care discutăm în detaliu în curs, dar facem și o aplicație de la zero.

Cam atât pentru azi, ne auzim data viitoare.