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

Ang materyal na ito ay bahagi ng seryeng "Introduction to Enterprise Development" . Ang unang bahagi, tungkol sa networking, ay narito . Ang arkitektura ng software ay tumutukoy sa istrukturang nilikha sa loob ng isang application, ibig sabihin, ang mga module at bahagi ng buong programa at kung paano sila nakikipag-ugnayan. Ang mga programmer ay nagtatrabaho sa magagandang arkitektura sa napakatagal na panahon, kaya hindi nakakagulat na marami kaming narinig na mga pattern ng arkitektura. Kailangan mong maunawaan ang mga ito: kapag nagsusulat ng web application, kritikal na magkaroon ng magandang arkitektura, dahil ang isang web application ay may mas maraming bahagi at module kaysa sa isang regular na application. Isang pattern ng arkitekturaay isang matalinong paraan upang malutas ang ilang problema sa disenyo ng software. Marahil ay nakatagpo ka ng mga pattern ng disenyo tulad ng factory method, abstract factory, builder, prototype, singleton, at posibleng iba pa. Ginagamit namin ang mga ito kapag nagsusulat ng code, gumagawa ng mga klase, at nagpaplano kung paano makikipag-ugnayan ang mga klase. Ginagamit ang mga pattern ng arkitektura sa mas mataas na antas ng abstraction, kapag pinaplano ang pakikipag-ugnayan ng user sa mga server, data, at iba pang bahagi. Tingnan natin ang ilang mga pattern at kung paano gamitin ang mga ito.

Arkitektura ng Client-server

Ang pangalan ay lumilikha ng impresyon na ang lahat tungkol sa pattern na ito ay simple at malinaw. Ngunit linawin natin ang ilang mga punto, upang kapag nagsimula kang mag-aral ng Spring ay maunawaan mo kung ano ang pinag-uusapan natin. Sabihin nating nagsulat ka ng isang chat app, at ikaw at ang isang kaibigan ay nagsimulang gumamit nito. Maaari kang gumamit ng napakasimpleng diskarte, direktang magpadala ng mga mensahe sa isa't isa sa pamamagitan ng Internet gamit ang mga kilalang IP address: Sa una, tila gumagana nang maayos ang lahat hanggang sa hilingin ng isa sa iyong mga kaibigan na sumali sa chat. Kaya kapag nagpasya kang idagdag ang iyong kapwa kaibigan sa chat, nahaharap ka sa isang problema sa arkitektura: para sa bawat kalahok sa chat, kailangan mong magbigay ng kasalukuyang impormasyon tungkol sa bilang ng mga user, at ang IP address ng mga bagong user. At kapag nagpadala ng mensahe, kailangan itong maihatid sa lahat ng kalahok. Ito ang mga pinaka-halatang problema na lilitaw. Ang isa pang grupo ng mga problema ay itatago sa code mismo. Upang maiwasan ang mga ito, kailangan mong gumamit ng isang server, na mag-iimbak ng lahat ng impormasyon tungkol sa mga user, kasama ang kanilang mga address. Kailangan lang ipadala ang mga mensahe sa server. Ito naman, ay nagpapadala ng mga mensahe sa bawat isa sa mga tatanggap. Kapag nagpasya kang magdagdag ng bahagi ng server sa iyong chat app, nagsisimula kang bumuo ng arkitektura ng client-server.

Mga bahagi ng arkitektura ng client-server

Tingnan natin kung ano ang tungkol dito. Ang arkitektura ng client-server ay isang pattern ng disenyo na ginagamit upang lumikha ng mga web application. Ang arkitektura na ito ay binubuo ng tatlong sangkap:

1. Client — Mula sa pangalan nito, masasabi natin na ang bahaging ito ay gumagamit ng ilang serbisyo (ang web application), na nakikipag-ugnayan sa isang server upang humiling ng ilang impormasyon.

2. Server — Dito matatagpuan ang iyong web application o ang bahagi ng server nito. Nag-iimbak ito ng kinakailangang impormasyon ng user o maaaring humiling nito. Bilang karagdagan, kapag ang isang kliyente ay nagpadala ng isang kahilingan, ito ay ang server na nagbabalik ng hiniling na impormasyon.

3. Network — Ang bahaging ito ay simple. Pinapadali nito ang pagpapalitan ng impormasyon sa pagitan ng kliyente at server.

Ang server ay maaaring hawakan ang isang malaking bilang ng mga kahilingan mula sa iba't ibang mga gumagamit. Nangangahulugan ito na maaaring maraming kliyente. Kung kailangan nilang makipagpalitan ng impormasyon sa kanilang sarili, dapat itong mangyari sa pamamagitan ng server. Kaya, ang server ay may isa pang function: kontrol sa trapiko. Tulad ng nauugnay sa aming multi-user chat program, ang lahat ng buong application ay bubuo ng dalawang module:

• isang client module — naglalaman ng isang graphical na interface para sa pag-sign in at pagpapadala/pagtanggap ng mga mensahe

• isang module ng server — 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, magbubukas kami ng browser, magpasok ng query sa search bar, at kumuha ng impormasyon mula sa search engine bilang tugon. Sa chain na ito, ang browser ay ang kliyente. Nagpapadala ito ng kahilingan na may impormasyon tungkol sa kung ano ang hinahanap namin sa server. Pinoproseso ng server ang kahilingan, hinahanap ang mga pinakanauugnay na resulta, ipino-package ang mga ito sa isang format na mauunawaan ng browser (client) at ibabalik ang mga ito. Ang mga kumplikadong serbisyo tulad ng mga search engine ay maaaring magkaroon ng maraming server. Halimbawa, isang server ng pahintulot, isang server para sa paghahanap ng impormasyon, isang server para sa pagbuo ng tugon, atbp. Ngunit ang kliyente ay walang kamalayan at walang pakialam sa alinman sa mga ito: para sa kliyente, ang server ay isang pinag-isang entity. Alam lang ng kliyente ang tungkol sa entry point, iyon ay, ang address ng server kung saan dapat ipadala ang mga kahilingan. Alalahanin ang application na aming sinuriang nakaraang bahagi ng seryeng ito . Ito ay para sa pagsubaybay sa average na temperatura ng hangin sa lahat ng mga bansa sa real time. Ang arkitektura nito ay ganito ang hitsura: Ang aming application ay matatagpuan sa server. Sabihin nating bawat limang segundo nagpapadala ito ng mga kahilingan sa mga server na pinapatakbo ng mga lokal na istasyon ng meteorolohiko, tumatanggap ng impormasyon sa temperatura para sa isang partikular na bansa mula sa mga server, at iniimbak ang impormasyong ito. Kapag hiniling sa amin ng kliyente na "tingnan ang kasalukuyang temperatura ng hangin sa mundo", ibinabalik namin ang pinakabagong nakaimbak na impormasyon, na pinagsunod-sunod ayon sa bansa. Kaya, ang aming application ay gumaganap bilang 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, gumagamit kami ng iba't ibang mga arkitektura, na makikilala mo sa hinaharap. Ngayon tingnan natin ang isang modelo na halos kapareho sa arkitektura ng client-server.

Tatlong antas na arkitektura

Ito ay isang pattern ng arkitektura na nagpapakilala ng ikatlong module — imbakan ng data . Sa pattern na ito, ang tatlong antas ay karaniwang tinatawag na mga layer o tier:

1. Ang client layer ay ang user interface, na tinatawag ding presentation tier. Ito ay maaaring isang web browser na tumatanggap ng mga HTML na pahina, o isang graphical na user interface na nakasulat gamit ang JavaFX. Ang pangunahing bagay ay ang layer na ito ay nagbibigay-daan sa user na magpadala ng mga kahilingan sa server at iproseso ang mga tugon nito.

2. Ang logic layer ay ang server na nagpoproseso ng mga kahilingan/tugon. Kadalasan ito ay tinatawag ding layer ng server. Dito rin nagaganap ang lahat ng lohikal na operasyon: mga kalkulasyon sa matematika, mga operasyon ng data, mga tawag sa iba pang mga serbisyo o mga imbakan ng data, atbp.

3. Ang data layer ay ang database server: ang aming server ay nakikipag-ugnayan dito. Iniimbak ng layer na ito ang lahat ng impormasyong kinakailangan para gumana ang application.

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

Mga kalamangan ng isang three-tier na arkitektura

Ang isang arkitektura na tulad nito ay nagbibigay sa amin ng maraming mga pakinabang, kabilang ang:

1. Ang kakayahang magprotekta laban sa SQL injection (ito ay isang pag-atake sa isang server; ito ay nagsasangkot ng pagpapadala ng SQL code na, kapag naisakatuparan, ay nagbibigay-daan sa isang umaatake na makaapekto sa aming database).

2. Paghihiwalay ng data kung saan gusto naming kontrolin ang access ng user.

3. Ang kakayahang baguhin ang data bago ipadala ito sa kliyente.

4. Scalability (ang kakayahang palawakin ang aming aplikasyon sa maraming server na gagamit ng parehong database.

5. Mas kaunting mahigpit na mga kinakailangan sa kalidad ng mga koneksyon ng user. Kapag bumubuo ng tugon sa server, madalas kaming nakakakuha ng maraming iba't ibang impormasyon mula sa isang database at i-format ito, na iniiwan lamang ang kailangan ng user. Ang paggawa nito ay binabawasan ang dami ng impormasyong ipinapadala namin sa aming tugon sa kliyente.

Gaano kadalas dapat gamitin ang mga pattern ng arkitektura?

Kung pamilyar ka sa, sabihin nating, ang pattern ng disenyo ng pamamaraan ng pabrika , malamang na nagtaka ka kung kailan ito gagamitin. Minsan mahirap magpasya kung ano ang gagawin: gumawa ng object gamit ang bagong operator o gamit ang factory method. Ngunit sa paglipas ng panahon, dumarating ang pagkakaunawaan. Medyo naiiba ang mga bagay pagdating sa mga pattern ng arkitektura. Ang mga balangkas ng negosyo ay idinisenyo upang payagan ang isang programmer na lumikha ng isang proyekto batay sa ilang karaniwang tinatanggap na pattern. Alinsunod dito, bago matutunan ang Spring Framework, dapat mong tiyak na maunawaan ang client-server architecture, three-tier architecture at MVC architecture. Huwag mag-alala: pag-uusapan pa natin ang tungkol sa arkitektura ng MVC. Bahagi 3. HTTP/HTTPS Bahagi 4. Ang mga pangunahing kaalaman ng Maven Bahagi 5. Mga Servlet at ang Java Servlet API. Pagsusulat ng simpleng web application Part 6. Mga lalagyan ng Servlet Part 7. Ipinapakilala ang pattern ng MVC (Model-View-Controller)