În acest articol vom cunoaște ceva numit MVC. Vom vorbi despre ce este MVC, vom atinge istoria sa, vom explora ideile și conceptele de bază încorporate în MVC, vom analiza pas cu pas cum să împărțim o aplicație în module Model, View și Controller, vom scrie o aplicație web mică folosind Spring Boot și, folosind Spring MVC ca exemplu, vedeți cum sunt trimise datele din codul Java către paginile HTML. Pentru a înțelege acest material, trebuie să fiți familiarizat cu modelele de design, în special cu observatorul și fațada. Și familiarizați-vă cu solicitările și răspunsurile HTTP, înțelegeți elementele de bază ale HTML și cunoașteți ce sunt adnotările Java. Luați o ceașcă de cafea și o gustare și vă simțiți confortabil. Sa incepem.
Istoria MVC
Ideile din spatele MVC au fost formulate de Trygve Reenskaug în timp ce lucra la Xerox PARC la sfârșitul anilor 1970. În acele vremuri, lucrul cu computerele necesita o diplomă și un studiu constant al documentației voluminoase. Sarcina rezolvată de Reenskaug împreună cu un grup de dezvoltatori foarte puternici a fost de a simplifica interacțiunea unui utilizator obișnuit cu computerul. Era necesar să se creeze instrumente care, pe de o parte, să fie extrem de simple și de înțeles, iar pe de altă parte, să facă posibilă controlul computerelor și aplicațiilor complexe. Reenskaug a lucrat într-o echipă care a dezvoltat un laptop „pentru copii de toate vârstele” - Dynabook, precum și limbajul SmallTalk sub conducerea lui Alan Kay. Atunci au fost stabilite conceptele unei interfețe prietenoase. În multe privințe, munca depusă de Reenskaug și echipa sa a influențat evoluția sferei IT. Iată un fapt interesant care nu se aplică direct MVC, dar ilustrează semnificația acestor evoluții. Alan Kaya spus, „Când am ajuns prima dată la Apple, care era în ’84, Mac-ul era deja scos și Newsweek m-a contactat și m-a întrebat ce părere am despre Mac. I-am spus: „Ei bine, Mac-ul este primul computer personal suficient de bun pentru fi criticat.' Așa că, după ce a anunțat iPhone-ul în 2007, mi l-a adus și mi l-a înmânat. El a spus: „Alan, este suficient de bun pentru a fi criticat?” Și i-am spus: „Steve, fă-l la fel de mare ca o tabletă și vei stăpâni lumea.” După 3 ani, pe 27 ianuarie 2010, Apple a introdus iPad-ul cu o diagonală de 9,7 inci. Cu alte cuvinte, Steve Jobs a urmat aproape exact sfatul lui Alan Kay. Proiectul lui Reenskaug a durat 10 ani. Dar prima publicație despre MVC a apărut după încă 10 ani. Martin Fowler, autor a mai multor cărți și articole despre arhitectura software, menționează că a studiat MVC folosind o versiune funcțională a Smalltalk. Deoarece nu au existat informații despre MVC din sursa originală pentru o lungă perioadă de timp și din mai multe alte motive, a apărut un număr mare de interpretări diferite ale acestui concept. Drept urmare, mulți consideră MVC un model de design. Mai rar, MVC este numit un model compozit sau o combinație de mai multe modele care lucrează împreună pentru a crea aplicații complexe. Dar, așa cum am menționat mai devreme, MVC este de fapt în primul rând un set de idei/principii/abordări arhitecturale care pot fi implementate în diferite moduri folosind diferite modele... În continuare, vom lua în considerare ideile principale încorporate în conceptul MVC. și din mai multe alte motive, au apărut un număr mare de interpretări diferite ale acestui concept. Drept urmare, mulți consideră MVC un model de design. Mai rar, MVC este numit un model compozit sau o combinație de mai multe modele care lucrează împreună pentru a crea aplicații complexe. Dar, așa cum am menționat mai devreme, MVC este de fapt în primul rând un set de idei/principii/abordări arhitecturale care pot fi implementate în diferite moduri folosind diferite modele... În continuare, vom lua în considerare ideile principale încorporate în conceptul MVC. și din mai multe alte motive, au apărut un număr mare de interpretări diferite ale acestui concept. Drept urmare, mulți consideră MVC un model de design. Mai rar, MVC este numit un model compozit sau o combinație de mai multe modele care lucrează împreună pentru a crea aplicații complexe. Dar, așa cum am menționat mai devreme, MVC este de fapt în primul rând un set de idei/principii/abordări arhitecturale care pot fi implementate în diferite moduri folosind diferite modele... În continuare, vom lua în considerare ideile principale încorporate în conceptul MVC.
MVC: Idei și principii de bază
VC este un set de idei și principii arhitecturale pentru construirea de sisteme informatice complexe cu o interfață cu utilizatorul
MVC este o abreviere care înseamnă: Model-View-Controller
Disclaimer: MVC nu este un model de design. MVC este un set de idei și principii arhitecturale pentru construirea de sisteme complexe cu o interfață cu utilizatorul. Dar pentru comoditate, pentru a nu spune în mod repetat „un set de idei arhitecturale...”, ne vom referi la modelul MVC. Să începem cu simplul. Ce se ascunde în spatele cuvintelor Model-View-Controller? Când utilizați modelul MVC pentru a dezvolta sisteme cu o interfață cu utilizatorul, trebuie să împărțiți sistemul în trei componente. Ele pot fi numite și module sau componente. Numiți-le cum doriți, dar împărțiți sistemul în trei componente. Fiecare componentă are propriul său scop. Model. Prima componentă/modul se numește model. Conține toată logica de afaceri a aplicației. Vedere.A doua parte a sistemului este vizualizarea. Acest modul este responsabil pentru afișarea datelor către utilizator. Tot ceea ce vede utilizatorul este generat de vizualizare. Controlor.A treia verigă din acest lanț este controlerul. Conține codul care este responsabil pentru gestionarea acțiunilor utilizatorului (toate acțiunile utilizatorului sunt gestionate în controler). Modelul este partea cea mai independentă a sistemului. Atât de independent încât nu trebuie să știe nimic despre modulele de vizualizare și controler. Modelul este atât de independent încât dezvoltatorii săi nu știu practic nimic despre vizualizare și controler. Scopul principal al vizualizării este de a oferi informații din model într-un format pe care utilizatorul îl poate consuma. Principala limitare a vederii este că nu trebuie să schimbe în niciun fel modelul. Scopul principal al controlorului este de a gestiona acțiunile utilizatorului. Prin intermediul controlerului utilizatorul face modificări la model. Sau mai precis, la datele care sunt stocate în model. Iată diagrama pe care ați văzut-o anterior în lecție: Din toate acestea, putem trage o concluzie logică. Un sistem complex trebuie împărțit în module. Să descriem pe scurt pașii pentru a realiza această separare.
Pasul 1. Separați logica de afaceri a aplicației de interfața cu utilizatorul
Ideea principală a MVC este că orice aplicație cu interfață utilizator poate fi împărțită în 2 module: un modul responsabil cu implementarea logicii de afaceri și interfața cu utilizatorul. Primul modul va implementa funcționalitatea principală a aplicației. Acest modul este nucleul sistemului, unde este implementat modelul de domeniu al aplicației. În paradigma MVC, acest modul este litera M, adică modelul. Al doilea modul implementează întreaga interfață cu utilizatorul, inclusiv logica de a afișa date utilizatorului și de a gestiona interacțiunea utilizatorului cu aplicația. Scopul principal al acestei separări este de a se asigura că nucleul sistemului („modelul” în terminologia MVC) poate fi dezvoltat și testat independent. După efectuarea acestei separări, arhitectura aplicației arată astfel:
Pasul 2 Utilizați modelul de observator pentru a face modelul și mai independent și pentru a sincroniza interfețele utilizator
Aici avem 2 obiective:
Obțineți o independență și mai mare pentru model
Sincronizați interfețele utilizator
Următorul exemplu vă va ajuta să înțelegeți ce înțelegem prin sincronizarea interfețelor utilizator. Să presupunem că cumpărăm un bilet de film online și vedem numărul de locuri disponibile în cinematograf. În același timp, altcineva poate cumpăra un bilet de film. Dacă această altă persoană cumpără un bilet înaintea noastră, am dori să vedem o scădere a numărului de locuri disponibile pentru ora de spectacol pe care o luăm în considerare. Acum să ne gândim cum poate fi implementat acest lucru în cadrul unui program. Să presupunem că avem nucleul sistemului nostru (modelul nostru) și interfața (pagina web pentru cumpărarea biletelor). Doi utilizatori încearcă să aleagă un loc în teatru simultan. Primul utilizator cumpără un bilet. Pagina web trebuie să arate celui de-al doilea utilizator că acest lucru s-a întâmplat. Cum ar trebui să se întâmple asta? Dacă actualizăm interfața din nucleu, atunci nucleul (modelul nostru) va depinde de interfață. Pe măsură ce dezvoltăm și testăm modelul, va trebui să ținem cont de diferitele modalități de actualizare a interfeței. Pentru a realiza acest lucru, trebuie să implementăm modelul observator. Acest model permite modelului să trimită notificări de modificare tuturor ascultătorilor. În calitate de ascultător de evenimente (sau observator), interfața de utilizator primește notificări și este actualizată. Pe de o parte, modelul de observator permite modelului să informeze interfața (vizualizarea și controlerul) că au avut loc schimbări fără să știe nimic despre el, rămânând astfel independent. Pe de altă parte, face posibilă sincronizarea interfețelor utilizator. trebuie să implementăm modelul observator. Acest model permite modelului să trimită notificări de modificare tuturor ascultătorilor. În calitate de ascultător de evenimente (sau observator), interfața de utilizator primește notificări și este actualizată. Pe de o parte, modelul de observator permite modelului să informeze interfața (vizualizarea și controlerul) că au avut loc schimbări fără să știe nimic despre el, rămânând astfel independent. Pe de altă parte, face posibilă sincronizarea interfețelor utilizator. trebuie să implementăm modelul observator. Acest model permite modelului să trimită notificări de modificare tuturor ascultătorilor. În calitate de ascultător de evenimente (sau observator), interfața de utilizator primește notificări și este actualizată. Pe de o parte, modelul de observator permite modelului să informeze interfața (vizualizarea și controlerul) că au avut loc schimbări fără să știe nimic despre el, rămânând astfel independent. Pe de altă parte, face posibilă sincronizarea interfețelor utilizator.
Pasul 3 Separați interfața în vizualizare și controler
Continuăm să împărțim aplicația în module, dar acum la un nivel inferior în ierarhie. La acest pas, interfața cu utilizatorul (pe care am separat-o într-un modul distinct la pasul 1) este împărțită într-o vizualizare și un controler. Este dificil să trasezi o linie strictă între vedere și controler. Dacă spunem că vizualizarea este ceea ce vede utilizatorul, iar controlerul este mecanismul care îi permite utilizatorului să interacționeze cu sistemul, ați putea sublinia o contradicție. Elementele de control, cum ar fi butoanele de pe o pagină web sau o tastatură virtuală de pe ecranul unui telefon, sunt practic parte a controlerului. Dar sunt la fel de vizibile pentru utilizator ca orice parte a vizualizării. Ceea ce vorbim cu adevărat aici este separarea funcțională. Sarcina principală a interfeței cu utilizatorul este de a facilita interacțiunea utilizatorului cu sistemul.
ieșire și afișarea comodă a informațiilor despre sistem pentru utilizator
introduceți datele și comenzile utilizatorului (comunicați-le sistemului)
Aceste funcții determină modul în care interfața utilizator ar trebui să fie împărțită în module. În final, arhitectura sistemului arată astfel: Și așa ajungem la o aplicație formată din trei module numite model, vedere și controler. Să rezumăm:
Conform principiilor paradigmei MVC, un sistem trebuie împărțit în module.
Cel mai important și independent modul ar trebui să fie modelul.
Modelul este nucleul sistemului. Ar trebui să fie posibil să fie dezvoltat și testat independent de interfața cu utilizatorul.
Pentru a realiza acest lucru, în primul pas de divizare, trebuie să împărțim sistemul într-un model și o interfață cu utilizatorul.
Apoi, folosind modelul de observator, întărim independența modelului și sincronizăm interfețele cu utilizatorul.
Al treilea pas este împărțirea interfeței cu utilizatorul într-un controler și vizualizare.
Tot ceea ce este necesar pentru a primi datele utilizatorului în sistem se află în controler.
Tot ceea ce este necesar pentru a furniza informații utilizatorului se află în vizualizare.
Încă un lucru important de discutat înainte de a vă putea bea ciocolată caldă.
Câteva despre modul în care vizualizarea și controlerul interacționează cu modelul
Prin introducerea de informații prin controler, utilizatorul schimbă modelul. Sau cel puțin, utilizatorul modifică datele modelului. Când utilizatorul primește informații prin elemente de interfață (prin vizualizare), utilizatorul primește informații despre model. Cum se întâmplă asta? Prin ce mijloace interacționează vizualizarea și controlerul cu modelul? La urma urmei, clasele vizualizării nu pot apela direct metodele claselor modelului pentru a citi/scrie date. Altfel, nu am putea spune că modelul este independent. Modelul este un set de clase strâns legate la care nici vizualizarea, nici controlerul nu ar trebui să aibă acces. Pentru a conecta modelul la vizualizare și controler, trebuie să implementăm modelul de proiectare a fațadei. Fațada modelului este stratul dintre model și interfața cu utilizatorul, prin care vizualizarea primește date formatate convenabil, iar Controller-ul modifică datele apelând pe fațadă metodele necesare. Până la urmă, totul arată așa:
MVC: Ce câștigăm?
Obiectivul principal al paradigmei MVC este separarea implementării logicii de afaceri (modelul) de vizualizarea acesteia (vizualizarea). Această separare crește posibilitățile de reutilizare a codului. Beneficiile MVC sunt cele mai evidente atunci când trebuie să prezentăm aceleași date în formate diferite. De exemplu, ca tabel, grafic sau diagramă (folosind diferite vizualizări). În același timp, fără a afecta modul în care sunt implementate vizualizările, putem schimba modul în care răspundem la acțiunile utilizatorului (clicuri pe butoane, introducerea datelor). Dacă urmați principiile MVC, puteți simplifica dezvoltarea de software, puteți crește lizibilitatea codului și puteți îmbunătăți extensibilitatea și mentenabilitatea. În articolul final din seria „Introducere în dezvoltarea întreprinderii”, ne vom uita la o implementare MVC construită folosind Spring MVC. Partea 8. Să scriem o aplicație mică folosind Spring Boot
În acest articol vom cunoaște ceva numit MVC. Vom vorbi despre ce este MVC, vom atinge istoria sa, vom explora ideile și conceptele de bază încorporate în MVC, vom analiza pas cu pas cum să împărțim o aplicație în module Model, View și Controller, vom scrie o aplicație web mică folosind Spring Boot și, folosind Spring MVC ca exemplu, vedeți cum sunt trimise datele din codul Java către paginile HTML. Pentru a înțelege acest material, trebuie să fiți familiarizat cu modelele de design, în special cu observatorul și fațada. Și familiarizați-vă cu solicitările și răspunsurile HTTP, înțelegeți elementele de bază ale HTML și cunoașteți ce sunt adnotările Java. Luați o ceașcă de cafea și o gustare și vă simțiți confortabil. Sa incepem.
Din toate acestea, putem trage o concluzie logică. Un sistem complex trebuie împărțit în module. Să descriem pe scurt pașii pentru a realiza această separare.
Și așa ajungem la o aplicație formată din trei module numite model, vedere și controler. Să rezumăm:
GO TO FULL VERSION