Del 2. La oss snakke litt om programvarearkitektur

Dette materialet er en del av serien "Introduksjon til bedriftsutvikling" . Den første delen, om nettverksbygging, er her . Programvarearkitektur refererer til strukturen som skapes i en applikasjon, dvs. hele programmets moduler og komponenter og hvordan de samhandler. Programmerere har jobbet med gode arkitekturer i veldig lang tid, så det er ikke overraskende at vi har hørt om mange arkitektoniske mønstre. Du må forstå dem: Når du skriver en webapplikasjon, er det avgjørende å komme opp med en god arkitektur, fordi en webapplikasjon har flere komponenter og moduler enn en vanlig applikasjon. Et arkitektonisk mønsterer en smart måte å løse noen programvaredesignproblemer. Du har sannsynligvis kommet over designmønstre som fabrikkmetode, abstrakt fabrikk, byggmester, prototype, singleton og muligens andre. Vi bruker dem når vi skriver kode, lager klasser og planlegger hvordan klassene skal samhandle. Arkitektoniske mønstre brukes på et høyere abstraksjonsnivå, når man planlegger brukerens interaksjon med servere, data og andre komponenter. La oss ta en rask titt på noen mønstre og hvordan du bruker dem.

Klient-server-arkitektur

Navnet skaper inntrykk av at alt ved dette mønsteret er enkelt og tydelig. Men la oss avklare noen punkter, slik at når du begynner å studere Spring vil du forstå hva vi snakker om. La oss si at du har skrevet en chat-app, og at du og en venn begynner å bruke den. Du kan bruke en veldig enkel tilnærming, og sende meldinger til hverandre direkte via Internett ved å bruke kjente IP-adresser: Til å begynne med fungerer alt tilsynelatende bra helt til en annen av vennene dine ber om å bli med i chatten. Så når du bestemmer deg for å legge til din felles venn i chatten, står du overfor et arkitektonisk problem: for hver chat-deltaker må du oppgi aktuell informasjon om antall brukere og IP-adressen til nye brukere. Og når en melding sendes, må den leveres til alle deltakerne. Dette er de mest åpenbare problemene som vil oppstå. En annen haug med problemer vil være skjult i selve koden. For å unngå dem må du bruke en server, som vil lagre all informasjon om brukere, inkludert adressene deres. Meldinger må bare sendes til serveren. Den sender på sin side meldinger til hver av mottakerne. Når du bestemmer deg for å legge til en serverdel til chat-appen din, begynner du å bygge en klient-server-arkitektur.

Komponenter av klient-server-arkitekturen

La oss se hva det handler om. En klient-server-arkitektur er et designmønster som brukes til å lage webapplikasjoner. Denne arkitekturen består av tre komponenter:

1. Klient — Fra navnet kan vi fortelle at denne komponenten bruker en tjeneste (webapplikasjonen), og kontakter en server for å be om informasjon.

2. Server — Det er her webapplikasjonen din eller serverdelen av den er plassert. Den lagrer nødvendig brukerinformasjon eller kan be om den. I tillegg, når en klient sender en forespørsel, er det serveren som returnerer den forespurte informasjonen.

3. Nettverk — Denne delen er enkel. Det letter utveksling av informasjon mellom klient og server.

Serveren kan håndtere et stort antall forespørsler fra forskjellige brukere. Det betyr at det kan være mange kunder. Hvis de trenger å utveksle informasjon seg imellom, må dette skje via serveren. Dermed har serveren en annen funksjon: trafikkkontroll. Når det gjelder chatteprogrammet vårt for flere brukere, vil hele applikasjonen bestå av to moduler:

• en klientmodul — inneholder et grafisk grensesnitt for pålogging og sending/mottak av meldinger

• en servermodul — en nettapplikasjon som ligger på en server og mottar meldinger fra brukere, behandler dem og sender dem til mottakere

Når vi ønsker å se på nyttig (eller lite nyttig) informasjon på Internett, åpner vi en nettleser, skriver inn et søk i søkefeltet og får informasjon fra søkemotoren som svar. I denne kjeden er nettleseren klienten. Den sender en forespørsel med informasjon om hva vi ser etter til serveren. Serveren behandler forespørselen, finner de mest relevante resultatene, pakker dem i et format nettleseren (klienten) kan forstå og sender dem tilbake. Komplekse tjenester som søkemotorer kan ha mange servere. For eksempel en autorisasjonsserver, en server for å finne informasjon, en server for å generere svaret, osv. Men klienten er uvitende om og bryr seg ikke om noe av dette: for klienten er serveren en enhetlig enhet. Klienten vet kun om inngangspunktet, dvs. adressen til serveren som forespørsler skal sendes til. Husk søknaden vi undersøkte iforrige del av denne serien . Det var for å overvåke gjennomsnittlig lufttemperatur i alle land i sanntid. Arkitekturen ser omtrent slik ut: Vår applikasjon er plassert på serveren. La oss si at hvert femte sekund sender den forespørsler til servere som drives av lokale meteorologiske stasjoner, mottar temperaturinformasjon for et bestemt land fra serverne og lagrer denne informasjonen. Når klienten ber oss "se verdens nåværende lufttemperatur", returnerer vi den sist lagrede informasjonen, sortert etter land. Dermed fungerer applikasjonen vår både som en server (når den behandler brukerforespørsler) og en klient (når den mottar informasjon fra andre servere). En enkel klient-server-arkitektur brukes svært sjelden og kun for svært enkle applikasjoner. For virkelig store og komplekse prosjekter bruker vi ulike arkitekturer, som du vil møte i fremtiden. La oss nå se på en modell som er veldig lik klient-server-arkitekturen.

Tre-lags arkitektur

Dette er et arkitektonisk mønster som introduserer en tredje modul - datalagring . I dette mønsteret kalles de tre nivåene vanligvis lag eller lag:

1. Klientlaget er brukergrensesnittet, også kalt presentasjonsnivået. Det kan være en nettleser som mottar HTML-sider, eller et grafisk brukergrensesnitt skrevet ved hjelp av JavaFX. Hovedsaken er at dette laget lar brukeren sende forespørsler til serveren og behandle svarene.

2. Det logiske laget er serveren som behandler forespørsler/svar. Ofte kalles det også serverlaget. Det er også her alle logiske operasjoner finner sted: matematiske beregninger, dataoperasjoner, anrop til andre tjenester eller datalagringer osv.

3. Datalaget er databaseserveren: serveren vår samhandler med den. Dette laget lagrer all informasjon som er nødvendig for at applikasjonen skal fungere.

Dermed påtar vår server seg alt ansvar for å få tilgang til dataene og tillater ikke brukeren å få direkte tilgang til dem.

Fordeler med en tre-lags arkitektur

En arkitektur som denne gir oss mange fordeler, inkludert:

1. Evnen til å beskytte mot SQL-injeksjon (dette er et angrep på en server; det innebærer å sende SQL-kode som, når den utføres, lar en angriper påvirke databasen vår).

2. Separasjon av dataene vi ønsker å kontrollere brukertilgang til.

3. Muligheten til å endre data før de sendes til klienten.

4. Skalerbarhet (muligheten til å utvide applikasjonen vår til flere servere som vil bruke samme database.

5. Mindre strenge krav til kvaliteten på brukerforbindelser. Når vi genererer en respons på serveren, får vi ofte mye forskjellig informasjon fra en database og formaterer den, slik at det kun blir igjen det brukeren trenger. Å gjøre dette reduserer mengden informasjon som vi sender i vårt svar til klienten.

Hvor ofte bør arkitektoniske mønstre brukes?

Hvis du er kjent med for eksempel fabrikkmetodens designmønster , har du sikkert lurt på når du skal bruke det. Noen ganger er det vanskelig å bestemme hva du skal gjøre: opprette et objekt ved å bruke den nye operatøren eller ved å bruke en fabrikkmetode. Men over tid kommer forståelsen. Ting er litt annerledes når det kommer til arkitektoniske mønstre. Enterprise-rammeverk er designet for å tillate en programmerer å lage et prosjekt basert på et generelt akseptert mønster. Følgelig, før du lærer Spring Framework, bør du definitivt forstå klient-server-arkitekturen, trelagsarkitekturen og MVC-arkitekturen. Ikke bekymre deg: vi vil ennå snakke om MVC-arkitekturen. Del 3. HTTP/HTTPS Del 4. Det grunnleggende om Maven Del 5. Servlets og Java Servlet API. Skrive en enkel nettapplikasjon Del 6. Servlet-beholdere Del 7. Introduserer MVC-mønsteret (Model-View-Controller)