Partea 2. Să vorbim puțin despre arhitectura software

Acest material face parte din seria „Introducere în dezvoltarea întreprinderii” . Prima parte, despre crearea de rețele, este aici . Arhitectura software se referă la structura creată în cadrul unei aplicații, adică la modulele și componentele întregului program și modul în care acestea interacționează. Programatorii au lucrat la arhitecturi bune de foarte mult timp, așa că nu este surprinzător că am auzit de multe modele arhitecturale. Trebuie să le înțelegeți: atunci când scrieți o aplicație web, este esențial să veniți cu o arhitectură bună, deoarece o aplicație web are mai multe componente și module decât o aplicație obișnuită. Un model arhitecturaleste o modalitate inteligentă de a rezolva o problemă de proiectare software. Probabil că ați întâlnit modele de design, cum ar fi metoda fabricii, fabrică abstractă, constructor, prototip, singleton și, posibil, altele. Le folosim atunci când scriem cod, creăm clase și planificăm modul în care vor interacționa clasele. Tiparele arhitecturale sunt utilizate la un nivel superior de abstractizare, atunci când se planifică interacțiunea utilizatorului cu servere, date și alte componente. Să aruncăm o privire rapidă asupra unor modele și cum să le folosim.

Arhitectura client-server

Numele creează impresia că totul despre acest model este simplu și clar. Dar haideți să lămurim câteva puncte, pentru ca atunci când veți începe să studiați Primăvara să înțelegeți despre ce vorbim. Să presupunem că ai scris o aplicație de chat și tu și un prieten începeți să o utilizați. Ați putea adopta o abordare foarte simplă, trimițându-vă mesaje unul altuia direct prin Internet folosind adrese IP cunoscute: La început, totul pare să funcționeze bine până când un alt prieten dintre prieteni vă cere să se alăture chatului. Deci, atunci când decideți să adăugați prietenul comun la chat, vă confruntați cu o problemă arhitecturală: pentru fiecare participant la chat, trebuie să furnizați informații actuale despre numărul de utilizatori și adresa IP a noilor utilizatori. Și atunci când un mesaj este trimis, acesta trebuie să fie livrat tuturor participanților. Acestea sunt cele mai evidente probleme care vor apărea. O altă grămadă de probleme vor fi ascunse în codul în sine. Pentru a le evita, trebuie să utilizați un server, care va stoca toate informațiile despre utilizatori, inclusiv adresele acestora. Mesajele trebuie trimise doar către server. Acesta, la rândul său, trimite mesaje fiecăruia dintre destinatari. Când decideți să adăugați o parte de server la aplicația dvs. de chat, începeți să construiți o arhitectură client-server.

Componente ale arhitecturii client-server

Să vedem despre ce este vorba. O arhitectură client-server este un model de design utilizat pentru a crea aplicații web. Această arhitectură constă din trei componente:

1. Client — Din numele său, putem spune că această componentă folosește un serviciu (aplicația web), contactând un server pentru a solicita unele informații.

2. Server — Aici se află aplicația dvs. web sau partea de server a acesteia. Stochează informațiile necesare despre utilizator sau le poate solicita. În plus, atunci când un client trimite o solicitare, serverul este cel care returnează informațiile solicitate.

3. Rețea — Această parte este simplă. Facilitează schimbul de informații între client și server.

Serverul poate gestiona un număr mare de solicitări de la diferiți utilizatori. Aceasta înseamnă că pot fi mulți clienți. Dacă trebuie să facă schimb de informații între ei, acest lucru trebuie să se întâmple prin intermediul serverului. Astfel, serverul are o altă funcție: controlul traficului. În ceea ce privește programul nostru de chat multi-utilizator, întreaga aplicație va consta din două module:

• un modul client — conține o interfață grafică pentru autentificare și trimitere/primire mesaje

• un modul de server — o aplicație web care este găzduită pe un server și care primește mesaje de la utilizatori, le procesează și apoi le trimite destinatarilor

Când vrem să privim informații utile (sau nu foarte utile) pe Internet, deschidem un browser, introducem o interogare în bara de căutare și obținem informații de la motorul de căutare ca răspuns. În acest lanț, browserul este clientul. Trimite serverului o solicitare cu informații despre ceea ce căutăm. Serverul procesează cererea, găsește cele mai relevante rezultate, le împachetează într-un format pe care browserul (clientul) îl poate înțelege și le trimite înapoi. Serviciile complexe precum motoarele de căutare pot avea o mulțime de servere. De exemplu, un server de autorizare, un server pentru găsirea de informații, un server pentru generarea răspunsului etc. Dar clientul nu este conștient și nu este preocupat de nimic din toate acestea: pentru client, serverul este o entitate unificată. Clientul știe doar despre punctul de intrare, adică adresa serverului la care trebuie trimise cererile. Amintiți-vă aplicația pe care am examinat-o înpartea anterioară a acestei serii . A fost pentru monitorizarea temperaturii medii a aerului în toate țările în timp real. Arhitectura sa arată cam așa: Aplicația noastră este localizată pe server. Să presupunem că la fiecare cinci secunde trimite cereri către serverele operate de stațiile meteorologice locale, primește informații despre temperatură pentru o anumită țară de la servere și stochează aceste informații. Când clientul ne cere „să vedem temperatura actuală a aerului din lume”, returnăm cele mai recente informații stocate, sortate după țară. Astfel, aplicația noastră acționează atât ca server (când procesează cererile utilizatorilor) cât și ca client (când primește informații de la alte servere). O arhitectură simplă client-server este folosită foarte rar și numai pentru aplicații foarte simple. Pentru proiecte cu adevărat mari și complexe, folosim arhitecturi diferite, pe care le veți întâlni în viitor. Acum să ne uităm la un model care este foarte asemănător cu arhitectura client-server.

Arhitectură cu trei niveluri

Acesta este un model arhitectural care introduce un al treilea modul - stocarea datelor . În acest model, cele trei niveluri sunt de obicei numite straturi sau niveluri:

1. Stratul client este interfața cu utilizatorul, numită și nivelul de prezentare. Poate fi un browser web care primește pagini HTML sau o interfață grafică de utilizator scrisă folosind JavaFX. Principalul lucru este că acest strat permite utilizatorului să trimită cereri către server și să proceseze răspunsurile acestuia.

2. Stratul logic este serverul care procesează cererile/răspunsurile. Adesea este numit și stratul de server. Tot aici au loc toate operațiunile logice: calcule matematice, operații de date, apeluri către alte servicii sau depozite de date etc.

3. Stratul de date este serverul bazei de date: serverul nostru interacționează cu acesta. Acest strat stochează toate informațiile necesare pentru ca aplicația să funcționeze.

Astfel, serverul nostru își asumă toată responsabilitatea pentru accesarea datelor și nu permite utilizatorului să le acceseze direct.

Avantajele unei arhitecturi cu trei niveluri

O arhitectură ca aceasta ne oferă multe avantaje, printre care:

1. Abilitatea de a proteja împotriva injectării SQL (acesta este un atac asupra unui server; implică trimiterea de cod SQL care, atunci când este executat, permite unui atacator să ne afecteze baza de date).

2. Separarea datelor la care dorim să controlăm accesul utilizatorilor.

3. Abilitatea de a modifica datele înainte de a le trimite către client.

4. Scalabilitate (abilitatea de a extinde aplicația noastră la mai multe servere care vor folosi aceeași bază de date.

5. Cerințe mai puțin stricte privind calitatea conexiunilor utilizatorilor. Când generăm un răspuns pe server, de multe ori obținem o mulțime de informații diferite dintr-o bază de date și o formatăm, lăsând doar ceea ce are nevoie utilizatorul. Acest lucru reduce cantitatea de informații pe care o trimitem clientului în răspunsul nostru.

Cât de des ar trebui folosite modelele arhitecturale?

Dacă sunteți familiarizat, de exemplu, cu modelul de proiectare a metodei din fabrică , probabil v-ați întrebat când să îl utilizați. Uneori este greu să decideți ce să faceți: creați un obiect folosind noul operator sau folosind o metodă din fabrică. Dar în timp, înțelegerea vine. Lucrurile sunt puțin diferite când vine vorba de modele arhitecturale. Cadrele pentru întreprinderi sunt concepute pentru a permite unui programator să creeze un proiect bazat pe un model general acceptat. În consecință, înainte de a învăța Spring Framework, ar trebui să înțelegeți cu siguranță arhitectura client-server, arhitectura cu trei niveluri și arhitectura MVC. Nu vă faceți griji: vom vorbi încă despre arhitectura MVC. Partea 3. HTTP/HTTPS Partea 4. Elementele de bază ale Maven Partea 5. Servlet-uri și API-ul Java Servlet. Scrierea unei aplicații web simplă Partea 6. Containere servlet Partea 7. Prezentarea modelului MVC (Model-View-Controller)