Ang tagsibol ay para sa mga tamad. Mga pangunahing kaalaman, pangunahing konsepto at mga halimbawa na may code. Bahagi 1

Maraming mga tao, pagkatapos basahin ang aking mga artikulo tungkol sa paglikha ng isang template para sa isang proyekto sa web at tungkol sa paglikha ng isang simpleng serbisyo sa web gamit ang mga servlet , ay nagtaka kung kailan ako magsusulat tungkol sa Spring. Hindi ko gusto, iminungkahi kong magbasa ng libro (at sinasabi ko pa rin na ang isang libro ay mas mahusay kaysa sa 10, o kahit na 100 na mga artikulo sa Internet). Ngunit ngayon napagpasyahan ko na ang pagpapaliwanag ng parehong bagay sa iba't ibang tao, gumugugol ako ng mas maraming oras kaysa kung umupo ako nang isang beses at nagsulat ng isang artikulo, at pagkatapos ay nag-post lamang ng isang link dito. Kaya nagsusulat ako para sa kapakanan ng link)). Sa artikulong ito hindi ako magsusulat kung paano gumawa ng isang gumaganang proyekto sa Spring sa loob ng 5 minuto kasunod ng aking halimbawa. Isusulat ko lamang ang tungkol sa mga pangunahing bagay, nang walang kaalaman kung saan tiyak na posible na magsimula ng isang proyekto, ngunit kung ano ang nangyayari doon, at, higit sa lahat, kung bakit, ay hindi magiging malinaw.

Ano ang Spring Framework?

Spring Framework , o simpleng Spring , ay isa sa pinakasikat na frameworks para sa paglikha ng mga web application sa Java. Ang isang balangkas ay isang bagay na katulad ng isang aklatan (marahil ang terminong ito ay mas pamilyar sa iyo), ngunit mayroong isang punto. Sa halos pagsasalita, gamit ang isang library, lumikha ka lamang ng mga bagay ng mga klase na nasa loob nito, tumawag sa mga pamamaraan na kailangan mo, at sa gayon ay makuha ang resulta na kailangan mo. Iyon ay, mayroong isang mas kinakailangan na diskarte: malinaw mong ipinapahiwatig sa iyong programa kung anong tiyak na sandali ang kailangan mong likhain kung aling bagay, sa anong sandali kailangan mong tumawag sa isang tiyak na pamamaraan, atbp. Sa mga balangkas, ang mga bagay ay bahagyang naiiba. Isulat mo lang ang ilan sa iyong sariling mga klase, isulat ang ilang bahagi ng lohika doon, at ang balangkas mismo ay lumilikha ng mga bagay ng iyong mga klase at tumatawag ng mga pamamaraan para sa iyo. Kadalasan, ang iyong mga klase ay nagpapatupad ng ilang mga interface mula sa balangkas o nagmamana ng ilang mga klase mula dito, kaya natatanggap ang ilan sa mga pag-andar na nakasulat na para sa iyo. Ngunit hindi ito kailangang maging ganoon. Sa Spring, halimbawa, sinusubukan nilang lumayo sa gayong mahigpit na pagsasama hangga't maaari (kapag ang iyong mga klase ay direktang nakasalalay sa ilang mga klase/interface mula sa balangkas na ito), at gumamit ng mga anotasyon para sa layuning ito. Babalik tayo sa puntong ito mamaya. Ngunit mahalagang maunawaan na ang Spring ay isang hanay lamang ng ilang mga klase at interface na naisulat na para sa iyo :) Gusto ko ring agad na tandaan na ang Spring ay maaaring gamitin hindi lamang para sa mga web application, kundi pati na rin para sa pinakakaraniwang console mga application na pamilyar sa ating lahat ng mga programa At ngayon ay magsusulat pa kami ng ganoon.

Istruktura

Ngunit ang Spring ay hindi isang tiyak na balangkas. Ito ay sa halip isang pangkalahatang pangalan para sa isang bilang ng mga maliliit na frameworks, bawat isa ay gumagawa ng ilang uri ng iba't ibang trabaho. Tulad ng nakikita mo, ang tagsibol ay may isang modular na istraktura. Ito ay nagpapahintulot sa amin na ikonekta lamang ang mga module na kailangan namin para sa aming aplikasyon at hindi ikonekta ang mga malinaw na hindi namin gagamitin. Sa pagkakaalam ko, ang diskarteng ito ang nakatulong sa Spring na malampasan ang katunggali nito noong panahong iyon (EJB) at manguna. Dahil ang mga application na gumagamit ng EJB ay nakakuha ng maraming dependency sa kanila, at sa pangkalahatan sila ay naging mabagal at malamya. Ang larawan ay nagpapakita na ang spring framework ay binubuo ng ilang mga module:

• pag-access ng data;
• web;
• core;
• at iba pa.

Ngayon ay makikilala natin ang ilang mga konsepto ng pangunahing modyul, tulad ng: beans, konteksto at iba pa. Tulad ng maaari mong hulaan, ang data access module ay naglalaman ng mga tool para sa pagtatrabaho sa data (pangunahin ang mga database), web - para sa pagtatrabaho sa network (kabilang ang para sa paglikha ng mga web application, na tatalakayin sa ibang pagkakataon). Bilang karagdagan, mayroon ding tinatawag na buong imprastraktura ng Spring: maraming iba pang mga proyekto na hindi opisyal na kasama sa mismong balangkas, ngunit walang putol na isinama sa iyong proyekto sa Spring (halimbawa, ang parehong seguridad sa tagsibol para sa pagtatrabaho sa awtorisasyon ng gumagamit sa site, na, sana, mararamdaman din natin balang araw).

Bakit Spring sa Java?

Buweno, bukod sa ito ay naka-istilong, naka-istilong, at kabataan, masasabi ko kaagad na sa sandaling makabisado mo ito kahit kaunti, mauunawaan mo kung gaano karaming iba't ibang trabaho ang hindi mo na kailangang gawin ngayon, at kung magkano ang Spring tumatagal sa. Maaari kang magsulat ng ilang dosenang linya ng mga config, magsulat ng ilang klase - at makakakuha ka ng isang gumaganang proyekto. Ngunit sa sandaling magsimula kang mag-isip tungkol sa kung magkano ang "sa ilalim ng talukbong", kung gaano karaming trabaho ang ginagawa, at gaano karaming code ang kailangang isulat kung gagawin mo ang parehong proyekto sa mga hubad na servlet o sa mga socket at purong Java - ang iyong buhok ay nakatayo sa dulo :) Mayroong kahit na tulad ng isang expression: tulad ng "magic" ng Spring. Ito ay kapag nakita mong gumagana ang lahat, ngunit tinatantya mo kung gaano karaming dapat mangyari doon para gumana ang lahat at kung paano gumagana ang lahat doon - pagkatapos ay tila lahat ng ito ay nangyayari salamat sa ilang uri ng mahika talaga)) Mas madaling gawin tawagan itong lahat ng magic kaysa subukang ipaliwanag kung paano magkakaugnay ang lahat doon. :) Well, ang pangalawang argumento "para sa" pag-aaral ng Spring ay na sa humigit-kumulang 90% ng mga bakante para sa isang junior (ayon sa aking mga personal na obserbasyon), alinman sa kaalaman o hindi bababa sa isang pangkalahatang ideya ng set ng ginoo ng Spring mula sa data, web-mvcat security:) ay kinakailangan lamang ang mga pangunahing kaalaman.

DI/IoC

Kung sinubukan mong magbasa ng isang bagay sa Spring, malamang na ang unang bagay na nakita mo ay ang mga titik na ito: DI/IoC . Ngayon, lubos kong inirerekumenda na magpahinga ka sa artikulong ito at basahin ang artikulong ito sa Habré ! IoC (Inversion of Control) - pagbabaligtad ng kontrol. Nabanggit ko na ito sa pagpasa noong isinulat ko na kapag gumagamit ng isang silid-aklatan, ikaw mismo ang sumulat sa iyong code kung aling paraan kung aling object ang tatawagan, at sa kaso ng mga balangkas, kadalasan ang balangkas ay tatawag sa code na iyong isinulat sa kanan sandali. Ibig sabihin, dito hindi mo na kinokontrol ang proseso ng pag-execute ng code/program, pero ginagawa ito ng framework para sa iyo. Inilipat mo ang kontrol sa kanya (inversion of control). Ang DI ay nauunawaan bilang Dependency Inversion (dependency inversion, iyon ay, sumusubok na huwag gumawa ng mahirap na koneksyon sa pagitan ng iyong mga module/klase, kung saan ang isang klase ay direktang nakatali sa isa pa), o Dependency Injection (dependency injection, ito ay kapag ang mga bagay na pusa ay hindi. nilikha mo sa pangunahing at pagkatapos ay ipapasa mo ang mga ito sa iyong mga pamamaraan, at nilikha ng Spring ang mga ito para sa iyo, at sasabihin mo lang sa kanya ang isang bagay tulad ng "Gusto kong makakuha ng pusa dito" at ipinasa niya ito sa iyo sa iyong pamamaraan). Mas madalas nating makakaharap ang pangalawa sa mga karagdagang artikulo.

Beans at konteksto

Isa sa mga pangunahing konsepto sa tagsibol ay bean . Sa esensya, ito ay isang bagay lamang ng ilang klase. Sabihin nating para sa aming programa kailangan naming gumamit ng 3 bagay: isang pusa, isang aso at isang loro. At mayroon kaming isang grupo ng mga klase na may isang grupo ng mga pamamaraan, kung saan kung minsan kailangan namin ng isang pusa para sa isang pamamaraan, at isang aso para sa isa pang pamamaraan, at kung minsan ay magkakaroon kami ng mga pamamaraan kung saan kailangan namin ng isang pusa at isang loro (halimbawa, isang pamamaraan para sa pagpapakain ng pusa, hehe), at sa ilang pamamaraan, kakailanganin ang lahat ng tatlong bagay. Oo, maaari muna nating likhain ang tatlong bagay na ito sa pangunahing, at pagkatapos ay ipasa ang mga ito sa ating mga klase, at mula sa loob ng mga klase hanggang sa mga pamamaraan na kailangan natin... At iba pa sa buong programa. At kung iniisip din natin na pana-panahong gusto nating baguhin ang listahan ng mga tinatanggap na parameter para sa ating mga pamamaraan (well, nagpasya kaming muling isulat ang isang bagay o magdagdag ng pag-andar) - pagkatapos ay kailangan nating gumawa ng maraming pag-edit sa code kung kailangan nating baguhin ang isang bagay. Ngayon, paano kung isipin natin na wala tayong 3, ngunit 300 tulad ng mga bagay? Ang isang alternatibo ay upang kolektahin ang lahat ng aming mga naturang bagay sa isang karaniwang listahan ng mga bagay ( List<Object> ) at ipasa ito sa lahat ng mga pamamaraan, at mula sa loob ng mga pamamaraan ay makuha ito o ang bagay na iyon na kailangan namin. Ngunit paano kung isipin natin na habang umuusad ang programa, maaaring maidagdag ang ilang bagay sa listahang ito, o (ano ang mas masahol pa) matanggal? Pagkatapos sa lahat ng mga pamamaraan kung saan kinukuha namin ang mga bagay mula sa listahan sa pamamagitan ng kanilang index, lahat ay maaaring masira. Pagkatapos ay nagpasya kaming mag-imbak hindi isang listahan, ngunit isang mapa, kung saan ang susi ay ang pangalan ng bagay na kailangan namin, at ang halaga ay ang bagay mismo, at pagkatapos ay maaari naming makuha ang mga bagay na kailangan namin mula dito sa pamamagitan lamang ng kanilang pangalan : get("parrot") at bilang tugon nakatanggap kami ng object parrot O, halimbawa, ang susi ay ang klase ng bagay, at ang halaga ay ang bagay mismo, kung gayon hindi na natin maipahiwatig ang pangalan ng bagay, ngunit ang klase lamang ng bagay na kailangan natin, na maginhawa rin. O kahit na magsulat ng ilang uri ng wrapper sa mapa, kung saan maaari kang lumikha ng mga pamamaraan upang sa ilang mga kaso maaari mong makuha ang mga bagay sa pamamagitan ng kanilang pangalan, at sa iba pang mga kaso ayon sa klase. Ito ang nakukuha natin mula sa konteksto ng aplikasyon sa tagsibol . Ang konteksto ay isang hanay ng mga beans (mga bagay). Ang pag-on sa konteksto, maaari nating makuha ang bean (bagay) na kailangan natin sa pamamagitan ng pangalan nito, halimbawa, o sa uri nito, o iba pa. Bilang karagdagan, maaari naming hilingin sa Spring na hanapin ang bean na kailangan namin sa konteksto nito at ipasa ito sa aming pamamaraan. Halimbawa, kung mayroon kaming pamamaraang tulad nito:

public void doSomething(Cat cat) {
    ...
}

Nang tinawag ng Spring ang paraang ito para sa amin, ipinasa nito ang bagay ng aming pusa mula sa konteksto nito papunta dito. Ngayon napagpasyahan namin na ang aming pamamaraan, bilang karagdagan sa isang pusa, ay nangangailangan din ng isang loro. Paggamit ng tagsibol - walang mas madali para sa amin! Sumulat lang kami:

public void doSomething(Cat cat, Parrot parrot) {
    ...
}

at Spring, kapag tinawag itong pamamaraan natin, ay mauunawaan na kailangan nating ipasa ang isang pusa at isang loro dito, pumunta sa konteksto nito, kunin ang dalawang bagay na ito at ipasa ang mga ito sa ating pamamaraan. Sa pamamagitan ng pagbibigay ng renda ng aming programa sa Spring, inilipat din namin sa kanya ang responsibilidad para sa paglikha ng mga bagay at pagpasa sa mga ito sa aming mga pamamaraan, na tatawagin niya. Ang tanong ay lumitaw: paano malalaman ng Spring kung aling mga bagay (bins) ang gagawin?

Mga Paraan ng Pag-configure ng Application

Mayroong tatlong pangunahing paraan upang i-configure ang isang application (iyon ay, sabihin sa Spring kung aling mga bagay ang kailangan nating gawin):

1. gamit ang xml file/configs;
2. gamit ang java configs;
3. awtomatikong pagsasaayos.

Inaayos ng mga developer ng tagsibol ang mga ito sa ganitong pagkakasunud-sunod ng priyoridad:

• ang pinaka-priyoridad na paraan na dapat bigyan ng kagustuhan ay awtomatikong pagsasaayos;
• kung gumagamit ng awtomatikong pagsasaayos hindi posible na wastong i-configure ang lahat ng posibleng beans, gamitin ang pagsasaayos ng Java (lumikha ng mga bagay gamit ang Java code);
• Well, ang pinakamababang priyoridad na paraan ay ang makalumang paraan, gamit ang xml configs.

Bilang karagdagan, pinapayagan ka ng Spring na pagsamahin ang mga pamamaraang ito. Halimbawa, hayaan ang Spring na gawin ang lahat ng maaaring awtomatikong i-configure; kung saan kailangan mong tukuyin ang ilang mga espesyal na parameter, gawin ito gamit ang mga Java config, at bilang karagdagan, maaari mong ikonekta ang ilang mga legacy na config sa xml na format. Sa pangkalahatan, ang lahat ng ito ay maaaring gawin nang may kakayahang umangkop. Ngunit gayon pa man, kung magagawa ang lahat gamit ang mga awtomatikong setting, gamitin ito. Isasaalang-alang ko lamang ang awtomatikong pagsasaayos at mga Java config; Ang mga xml config ay ginagamit na sa halos bawat halimbawa ng Spring sa Internet, at kapag naunawaan mo na kung paano gumagana ang configuration ng Java, hindi dapat magkaroon ng problema sa "pagbasa" ng isang xml file na gumagawa ng parehong bagay. Ang awtomatikong pagsasaayos ay ginagamit kapag ang mga bagay na kailangan namin para sa trabaho ay mga bagay ng mga klase na aming isinulat . Kung ang ilang partikular na lohika ay kinakailangan upang lumikha ng isang bagay ng aming klase, o kung wala kaming pagkakataon na markahan ang ilang klase ng anotasyon na kailangan namin, na kukunin ng awtomatikong pagsasaayos, maaari itong gawin sa mga Java config. . Sa susunod na bahagi , gagawa kami ng isang maven project, ikonekta ang isang pares ng mga central spring modules dito at gagawa ng aming unang beans.