Bahagi 2. Pag-usapan natin nang kaunti ang tungkol sa arkitektura ng software

Ang materyal na ito ay bahagi ng seryeng " Introduction to Enterprise Development ". Ang unang bahagi tungkol sa network ay narito . Ang arkitektura ng software ay ang istraktura na batayan kung saan nilikha ang isang application at ang mga module at bahagi ng buong programa ay nakikipag-ugnayan. Sinusubukan ng mga programmer na lumikha ng magandang arkitektura sa loob ng napakatagal na panahon, kaya hindi nakakagulat na marami na tayong alam na mga pattern ng arkitektura. Kailangan mong maunawaan ang mga ito: kapag sumulat ka ng isang web application, ang problema ng arkitektura ay nagiging talamak, dahil mayroong higit pang mga bahagi at mga module sa loob nito kaysa sa isang regular na aplikasyon. Ang isang pattern ng arkitektura ay isang naisip nang paraan upang malutas ang ilang problema sa disenyo ng software. Marahil ay nakatagpo ka na ng mga pattern ng disenyo tulad ng Factory Method, Abstract Factory, Builder, Prototype, Singleton, at marahil iba pa. Ginagamit ang mga ito upang magsulat lamang ng code, lumikha ng mga klase, at magplano kung paano sila nakikipag-ugnayan. Ginagamit ang mga pattern ng arkitektura sa mas mataas na antas ng abstraction - kapag pinaplano ang pakikipag-ugnayan ng user ng application sa server, data at iba pang bahagi ng proyekto. Tingnan natin ang ilang mga template at kung paano gamitin ang mga ito.

Arkitektura ng Client-server

Mula sa pangalan ang isa ay nakakakuha ng impresyon na ang lahat ng bagay sa paksang ito ay simple at malinaw. Ngunit linawin natin ang ilang mga punto upang kapag sinimulan mong pag-aralan ang conditional Spring, naiintindihan mo nang eksakto kung ano ang pinag-uusapan natin. Sabihin nating nagsulat ka ng chat, at sinimulan mong gamitin ito ng iyong kaibigan. Posible ang isang simpleng opsyon dito - direkta kang magpadala ng mensahe sa isa't isa sa pamamagitan ng Internet gamit ang mga IP address na alam mo: Sa una, maaaring mukhang maayos ang lahat, hanggang sa lumitaw ang isa pang kaibigan mo na may tanong na: "Bakit hindi Hindi mo ba ako ina-add sa chat mo?" At kapag nagpasya kang magdagdag ng kapwa kaibigan sa chat, nahaharap ka sa isang problema sa arkitektura: ang bawat user ng chat ay kailangang mag-update ng impormasyon tungkol sa bilang ng mga user, idagdag ang IP address ng bagong user. At kapag nagpapadala ng mensahe, dapat itong maihatid sa lahat ng kalahok. Ito ang mga pinaka-halatang problema na lilitaw. Marami pang problema ang itatago sa mismong code. Upang maiwasan ang mga ito, kailangan mong gumamit ng isang server na mag-iimbak ng lahat ng impormasyon tungkol sa mga gumagamit at alam ang kanilang mga address. Kakailanganin lamang na ipadala ang mensahe sa server. At siya naman ay magpapadala ng mensahe sa lahat ng tatanggap. Kapag nagpasya kang magdagdag ng bahagi ng server sa iyong chat, magsisimula kang bumuo ng isang arkitektura ng client-server.

Mga bahagi ng arkitektura ng client-server

Alamin natin kung ano siya. Ang arkitektura ng Client-server ay isang pattern ng disenyo, ang batayan para sa paglikha ng mga web application. Ang arkitektura na ito ay binubuo ng tatlong bahagi:

1. Kliyente - mula sa pangalan ay nagiging malinaw na ito ay isang gumagamit ng isang serbisyo (web application) na nakikipag-ugnayan sa server upang makakuha ng ilang impormasyon.

2. Ang server ay ang lugar kung saan matatagpuan ang iyong web application o ang bahagi ng server nito. Siya ang nagmamay-ari ng kinakailangang impormasyon tungkol sa mga user o maaaring humiling nito. Gayundin, kapag nakipag-ugnayan ang isang kliyente, ibinabalik ng server ang hiniling na impormasyon.

3. Ang network ay simple: tinitiyak nito ang pagpapalitan ng impormasyon sa pagitan ng kliyente at ng server.

Ang server ay maaaring magproseso ng isang malaking bilang ng mga kahilingan mula sa iba't ibang mga gumagamit. Iyon ay, maaaring mayroong maraming mga kliyente, at kung kailangan nilang makipagpalitan ng impormasyon sa isa't isa, ito ay kailangang gawin sa pamamagitan ng server. Kaya, ang server ay tumatanggap ng isa pang karagdagang function - kontrol sa trapiko. Kung pinag-uusapan natin ang multi-user na chat na nilikha namin, ang buong code ng programa ay bubuo ng dalawang module:

• client - naglalaman ng isang graphical na interface para sa awtorisasyon, pagpapadala/pagtanggap ng mga mensahe;

• server-side - isang web application na naka-host sa isang server at tumatanggap ng mga mensahe mula sa mga user, pinoproseso ang mga ito, at pagkatapos ay ipinapadala ang mga ito sa mga tatanggap.

Kapag gusto naming tumingin ng kapaki-pakinabang (o hindi masyadong kapaki-pakinabang) na impormasyon sa Internet, nagbubukas kami ng browser, nagpasok ng query sa search bar, at bilang tugon ay tumatanggap kami ng impormasyon mula sa search engine. Sa chain na ito, ang browser ay ang aming kliyente. Nagpapadala ito ng kahilingan na may impormasyon tungkol sa kung ano ang hinahanap namin sa server. Pinoproseso ng server ang kahilingan, hahanapin ang mga pinaka-kaugnay na resulta, i-package ang mga ito sa isang format na naiintindihan ng browser (kliyente) at ibabalik ang mga ito. Sa mga kumplikadong serbisyo tulad ng mga search engine, maaaring mayroong maraming mga server. Halimbawa, isang server ng awtorisasyon, isang server para sa paghahanap ng impormasyon, isang server para sa pagbuo ng isang tugon. Ngunit walang alam ang kliyente tungkol dito: para sa kanya, ang server ay isang bagay na pinag-isa. Alam lamang ng kliyente ang tungkol sa entry point, iyon ay, ang address ng server kung saan kailangan nitong ipadala ang kahilingan. Tandaan natin ang application na tiningnan natin sa nakaraang bahagi - para sa pagsubaybay sa average na temperatura ng hangin sa lahat ng mga bansa sa real time. Ang arkitektura nito ay magmumukhang ganito: Ang aming application ay matatagpuan sa isang server. Sabihin nating, bawat limang segundo nagpapadala ito ng mga kahilingan sa mga server ng mga lokal na hydrometeorological center, tumatanggap ng impormasyon mula sa kanila tungkol sa temperatura sa isang partikular na bansa, at iniimbak ang impormasyong ito. Kapag nakipag-ugnayan sa amin ang isang kliyente na may kahilingang "tingnan ang kasalukuyang temperatura ng hangin sa mundo," ibinabalik namin ang pinakabagong nakaimbak na impormasyon, na pinagsunod-sunod ayon sa bansa. Kaya, ang aming aplikasyon ay parehong server (kapag pinoproseso nito ang mga kahilingan ng user) at isang kliyente (kapag nakatanggap ito ng impormasyon mula sa ibang mga server). Ang isang simpleng arkitektura ng client-server ay bihirang ginagamit at para lamang sa mga napakasimpleng aplikasyon. Para sa talagang malaki at kumplikadong mga proyekto, iba't ibang uri ng mga arkitektura ang ginagamit, na mas magiging pamilyar ka sa hinaharap. Sa ngayon, tingnan natin ang isang modelo na halos kapareho sa isang modelo ng client-server.

Tatlong antas na arkitektura

Ito ay isang pattern ng arkitektura na nagpapakilala ng ikatlong manlalaro: ang data warehouse . Kapag ginagamit ang pattern na ito, ang tatlong antas ay karaniwang tinatawag na mga layer:

1. Ang client layer ay ang user interface. Ito ay maaaring isang web browser kung saan ipinapadala ang mga HTML na pahina, o isang GUI application na isinulat gamit ang JavaFX. Ang pangunahing bagay ay na sa tulong nito ang gumagamit ay maaaring magpadala ng mga kahilingan sa server at iproseso ang mga tugon nito.

2. Ang logic layer ay ang server kung saan pinoproseso ang mga kahilingan/tugon. Madalas din itong tinatawag na layer ng server. Ang lahat ng mga lohikal na operasyon ay nagaganap din dito: mga kalkulasyon sa matematika, mga pagpapatakbo ng data, mga tawag sa iba pang mga serbisyo o imbakan ng data.

3. Ang layer ng data ay ang database server: ina-access ito ng aming server. Iniimbak ng layer na ito ang lahat ng kinakailangang impormasyon na ginagamit ng application sa panahon ng operasyon.

Kaya, inaako ng aming server ang lahat ng obligasyon para sa pag-access ng data, nang hindi pinapayagan ang user na direktang ma-access ito.

Mga pakinabang ng isang three-tier na arkitektura

Gamit ang gayong arkitektura, nakakakuha kami ng maraming pakinabang, kabilang ang:

1. Ang kakayahang bumuo ng proteksyon laban sa mga SQL injection ay isang pag-atake sa server kung saan ipinapadala ang SQL code, at kapag naisakatuparan ang code na ito, maaaring maapektuhan ng attacker ang aming database.

2. Delimitation ng data kung saan gusto naming i-regulate ang access ng user.

3. Kakayahang baguhin ang data bago ipadala ito sa kliyente.

4. Scalability - ang kakayahang palawakin ang aming application sa ilang mga server na gagamit ng parehong database.

5. Mas kaunting mga kinakailangan para sa kalidad ng koneksyon ng user. Kapag bumubuo ng tugon sa server, madalas kaming kumukuha ng maraming iba't ibang impormasyon mula sa database, i-format ito, na iniiwan lamang ang kailangan ng gumagamit. Sa ganitong paraan binabawasan namin ang dami ng impormasyong ipinapadala namin bilang tugon sa kliyente.

Gaano kadalas mo dapat gamitin ang mga pattern ng arkitektura?

Kung pamilyar ka sa, sabihin nating, ang pattern ng disenyo ng Factory Method , malamang na iniisip mo kung kailan ito gagamitin. Minsan mahirap magpasya kung ano ang gagawin: lumikha ng isang bagay gamit ang bagong operator o gamit ang isang factory method. Ngunit sa paglipas ng panahon, dumarating ang pagkakaunawaan. Sa mga pattern ng arkitektura, ang mga bagay ay medyo naiiba. Ang mga enterprise framework ay idinisenyo para sa programmer na gamitin ang mga ito upang lumikha ng isang proyekto batay sa ilang karaniwang tinatanggap na pattern. Samakatuwid, bago matutunan ang Spring Framework, tiyak na kailangan mong maunawaan kung ano ang arkitektura ng client-server, three-tier na arkitektura at arkitektura ng MVC. Huwag mag-alala: pag-uusapan natin ang tungkol sa arkitektura ng MVC mamaya. Part 1. Ano ang kailangan mong malaman bago matutunan ang Spring at JavaEE Part 3. HTTP/HTTPS protocols Part 4. Maven basics Part 5. Servlets. Pagsusulat ng simpleng web application Part 6. Servlet container Part 7. Introducing the MVC (Model-View-Controller) pattern Part 8. Pagsusulat ng maliit na spring-boot application