Жаз жалкоолорго. Негиздери, негизги түшүнүктөр жана код менен мисалдар. 1-бөлүк

Көптөгөн адамдар менин веб-долбоор үчүн шаблон түзүү жана сервлеттерди колдонуу менен жөнөкөй веб-сервис түзүү жөнүндө макалаларымды окугандан кийин , Жаз жөнүндө качан жазам деп таң калышты. Мен каалаган жокмун, китеп окууну сунуштадым (мен дагы эле китеп интернеттеги 10, жада калса 100 макаладан жакшы деп айтам). Бирок азыр мен бир эле нерсени ар кандай адамдарга түшүндүрүп, мен бир жолу отуруп, макала жазып, анан ага шилтеме бергенге караганда көбүрөөк убакыт коротууну чечтим. Ошентип, мен шилтеме үчүн жазып жатам)). Бул макалада мен өзүмдүн үлгүм менен 5 мүнөттүн ичинде жазында жумушчу долбоорду кантип жасоону жазбайм. Мен негизги нерселер жөнүндө гана жазам, аларды билбей туруп, албетте, долбоорду баштоого болот, бирок ал жерде эмне болуп жатканы жана, андан да маанилүүсү, эмне үчүн ачык-айкын болбойт.

Spring Framework деген эмне?

Spring Framework же жөн эле Жаз , Java'да веб тиркемелерди түзүү үчүн эң популярдуу алHowтардын бири. АлHow китепканага окшош нерсе (балким, бул термин сизге көбүрөөк тааныш), бирок бир жагдай бар. Болжол менен айтканда, китепкананы колдонуу менен, сиз жөн гана андагы класстардын an objectтерин түзүп, керектүү ыкмаларды чакырып, ошону менен керектүү натыйжаны аласыз. Башкача айтканда, бир кыйла императивдик ыкма бар: сиз программаңызда кайсы конкреттүү учурда кайсы an objectти түзүү керек, кайсы учурда конкреттүү ыкманы чакыруу керек ж.б.у.с. так көрсөтөсүз. АлHowтар ​​менен, нерселер бир аз башкача. Сиз жөн гана өзүңүздүн кээ бир класстарыңызды жазасыз, логиканын бир бөлүгүн ошол жерге жазасыз, ал эми алHow өзү класстарыңыздын an objectтерин түзөт жана сиз үчүн методдорду чакырат. Көбүнчө класстарыңыз алHowтан кээ бир интерфейстерди ишке ашырат же андан кээ бир класстарды мурастап алат, ошентип сиз үчүн мурунтан эле жазылган кээ бир функцияларды алышат. Бирок андай болбошу керек. Мисалы, жазда алар мындай катуу туташуудан мүмкүн болушунча алыс болууга аракет кылышат (качан сиздин класстарыңыз түздөн-түз ушул алHowтагы кээ бир класстарга/интерфейстерге көз каранды болгондо) жана бул максатта annotationларды колдонушат. Бул пунктка кийинчерээк кайрылып келебиз. Бирок жаз бул сиз үчүн буга чейин жазылган класстардын жана интерфейстердин жыйындысы экенин түшүнүү керек :) баарыбызга тааныш болгон колдонмолор Ал эми бүгүн биз да ушундай бир нерсени жазабыз.

Структура

Бирок жаз бир конкреттүү алHow эмес. Бул, тескерисинче, ар бири ар кандай жумуштарды аткарган бир нече кичинекей алHowтардын жалпы аталышы. Көрүнүп тургандай, булак модулдук түзүлүшкө ээ. Бул бизге колдонмобуз үчүн керек болгон модулдарды гана туташтырууга мүмкүндүк берет, ал эми биз колдонбой тургандарын туташтырбай. Менин бorшимче, дал ушул ыкма Жазга ошол кездеги атаандашынан (EJB) ашып өтүп, лидерликке ээ болууга жардам берген. Анткени EJB колдонгон тиркемелер алар менен көптөгөн көз карандылыктарды тартып алышкан жана жалпысынан алар жай жана олдоксон болуп чыкты. Сүрөт жазгы алHow бир нече модулдардан турат экенин көрсөтүп турат:

• маалыматтарга кирүү;
• желе;
• өзөк;
• жана башкалар.

Бүгүн биз негизги модулдун кээ бир түшүнүктөрү менен таанышабыз, мисалы: буурчак, контекст жана башкалар. Сиз ойлогондой, маалыматтарга кирүү модулу маалыматтар менен иштөө үчүн куралдарды камтыйт (негизинен маалымат базалары), веб - тармакта иштөө үчүн (анын ичинде веб-тиркемелерди түзүү үчүн, алар кийинчерээк талкууланат). Мындан тышкары, бүткүл жазгы инфраструктура деп аталган дагы бар: алHowтын өзүнө расмий түрдө кирбеген, бирок жазгы долбооруңузга үзгүлтүксүз интеграцияланган көптөгөн башка долбоорлор (мисалы, колдонуучунун авторизациясы менен иштөө үчүн ошол эле жазгы коопсуздук . сайт, мен ишенем, биз да качандыр бир күнү сезебиз).

Эмне үчүн Java-жылы жаз?

Анын модалуу, саркеч, жаштыгынан тышкары, аны бир аз болсо да өздөштүрсөңүз, азыр канчалаган түрдүү жумуштардын кереги жок экенин, Жаздын канча экенин түшүнөсүз деп дароо айта алам. өзүнө алат. Сиз бир нече ондогон сап конфигурацияларды жаза аласыз, бир нече класстарды жаза аласыз - ошондо сиз жумушчу долбоор аласыз. Бирок сиз "капоттун астында" канча бар экендиги жөнүндө ойлоно баштаганыңызда, канча иш жасалып жатканы жана эгер сиз ошол эле долбоорду жылаңач сервлеттерде же розеткаларда жана таза Javaда жасасаңыз, канча code жазылышы керек эле. - чачың тик турат :) Жаздын "сыйкырындай" да ушундай сөз бар. Бул жерде сиз баары иштеп жатканын көрүп, бирок баары иштеши үчүн ал жерде канча болушу керек экенин жана ал жерде баары кандай иштээрин болжолдуу түрдө баалайсыз - анда мунун баары кандайдыр бир сыйкырдын аркасында болуп жаткандай сезилет)) Бул оңой мунун баарын сыйкыр деп атаңыз, анын баары ошол жерде кандайча өз ара байланышта экенин түшүндүрүүгө аракет кылыңыз. жылмаюу data_ web-mvc_ security_ жөн гана негиздер.

DI/IoC

Эгер сиз Жазда бир нерсе окууга аракет кылсаңыз, анда сиз биринчи жолу бул тамгалар болгон: DI/IoC . Эми мен сизге бул макаладан тыныгууну жана Хабредеги бул макаланы окууну сунуштайм ! IoC (Inversion of Control) - башкаруунун инversionсы. Мен китепкананы колдонууда кайсы an objectти чакырууну өзүңүздүн codeуңузга жазасыз, ал эми фреймворктордо көбүнчө сиз оң жакта жазган codeду алHow чакырат деп жазганымда, мен бул жөнүндө өткөндө айттым. учур. Башкача айтканда, бул жерде сиз codeду/программаны аткаруу процессин мындан ары башкара албайсыз, бирок рамка муну сиз үчүн кылат. Сиз ага башкарууну өткөрүп бердиңиз (контролдун инversionсы). DI көз карандылыктын инversionсы (көз карандылыктын инversionсы, башкача айтканда, бир класс экинчисине түздөн-түз байланышкан модулдарыңыздын/класстарыңыздын ортосунда катуу байланыштарды түзбөөгө аракет кылуу) же Көз карандылык инversionсы (көз карандылык инъекциясы, бул мышык an objectтери жок болгондо) деп түшүнүлөт. негизги сиз жараткан, анан сиз аларды методдоруңузга өткөрүп бересиз, ал эми Жаз аларды сиз үчүн жаратат, сиз ага жөн гана "мен бул жерден мышыкты алгым келет" деген сыяктуу нерсени айтсаңыз, ал аны сиздин методуңузда сизге өткөрүп берет). Биз кийинки макалаларда экинчисин көп жолуктурабыз.

Фасоль жана контекст

Жаздагы негизги түшүнүктөрдүн бири төө буурчак . Негизи, бул кандайдыр бир класстын an objectиси . Биздин программа үчүн 3 an objectти колдонушубуз керек дейли: мышык, ит жана тоту куш. Ал эми бизде бир топ методдор бар класстар бар, мында кээде ыкма үчүн мышык керек, башка ыкма үчүн ит керек, кээде бизде мышык менен тоту куш керек болгон методдор болот (мисалы, метод мышыкты тамактандыруу үчүн, хехе) жана кээ бир ыкмаларда үч an object тең керек болот. Ооба, биз адегенде бул үч an objectти негизгиде түзө алабыз, анан аларды класстарыбызга, класстардын ичинен бизге керектүү методдорго өткөрө алабыз... Программанын боюнда жана башкалар. Жана ошондой эле биз мезгил-мезгor менен биздин методдорубуз үчүн кабыл алынган параметрлердин тизмесин өзгөртүүнү каалай турганыбызды элестетсек (жакшы, биз бир нерсени кайра жазууну же функционалдуулукту кошууну чечтик) - анда бизге керек болсо, codeго бир топ түзөтүүлөрдү жасоого туура келет. бир нерсени өзгөртүү. Эми бизде 3 эмес, 300дөй an object бар деп элестетсекчи? Альтернатива – биздин ушундай an objectилердин бардыгын an objectтердин жалпы тизмесине чогултуу ( List<Object> ) жана аны бардык методдорго өткөрүп берүү жана методдордун ичинен бизге керектүү тигил же бул an objectти алуу. Бирок, программанын өнүгүшү менен бул тизмеге кандайдыр бир an object кошулушу мүмкүн же (эмнеси жаман) жок кылынышы мүмкүн деп элестетсекчи? Андан кийин биз тизмеден an objectтерди индекси боюнча алып чыккан бардык ыкмаларда бардыгы бузулушу мүмкүн. Андан кийин биз тизмени эмес, картаны сактоону чечебиз, анда ачкыч бизге керектүү an objectтин аты болот, ал эми маани an objectтин өзү болот, андан кийин биз андан керектүү an objectтерди жөн эле алардын аты менен ала алабыз. : get("parrot") жана жооп катары биз тоту куштун an objectисин алдык Же, мисалы, ачкыч an objectтин классы, ал эми маани an objectтин өзү болсо, анда биз мындан ары an objectтин атын эмес, жөн гана бизге керектүү an objectтин классын көрсөтө алабыз, бул да ыңгайлуу. Же болбосо, картанын үстүнө кандайдыр бир оромонун түрүн жазыңыз, анда сиз кээ бир учурларда an objectтерди алардын аты боюнча, ал эми башка учурларда класс боюнча алуу үчүн ыкмаларды жасай аласыз. Бул жазгы колдонмо контекстинен алган нерсебиз . Контекст - бул буурчактардын (an objectтердин) жыйындысы. Контекстке кайрылсак, бизге керек болгон буурчакты (an objectини) аты боюнча, мисалы, түрү боюнча, же башка нерсе боюнча алсак болот. Мындан тышкары, биз Жаздан бизге керектүү төө буурчакты анын контекстинде издеп, аны биздин ыкмабызга өткөрүп берүүнү сурансак болот. Мисалы, бизде мындай ыкма болсо:

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

Жаз бул ыкманы биз үчүн чакырганда, ал биздин мышыктын an objectисин контексттен ага өткөрүп берди. Эми биздин ыкмага мышыктан тышкары тоту куш керек деп чечтик. Жазды колдонуу - биз үчүн эч нерсе оңой эмес! Биз жөн гана жазабыз:

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

ал эми Жаз, бул ыкмабызды атаганда, бул жерде мышык менен тоту кушту өткөрүп, анын контекстине барып, бул эки an objectти алып, биздин методубузга өткөрүп беришибиз керек экенин түшүнөт. Программабыздын тизгинин Жазга өткөрүп берүү менен биз ага an objectтерди түзүү жана ал чакырган методдорубузга өткөрүп берүү жоопкерчorгин да өткөрүп алдык. Суроо туулат: Жаз кайсы an objectтерди (урналарды) түзүү керектигин кайдан билет?

Колдонмонун конфигурациясынын ыкмалары

Тиркемени конфигурациялоонун үч негизги жолу бар (башкача айтканда, Жазга кайсы an objectтерде иштешибиз керектигин айтыңыз):

1. xml файлдарын/конфигурацияларын колдонуу;
2. java конфигурацияларын колдонуу;
3. автоматтык конфигурация.

Жазгы иштеп чыгуучулар аларды артыкчылыктуу тартипте жайгаштырышат:

• артыкчылык берorши керек болгон эң приоритеттүү ыкма - автоматтык конфигурация;
• эгерде автоматтык конфигурацияны колдонуу менен бардык мүмкүн болгон буурчакты туура конфигурациялоо мүмкүн болбосо, Java конфигурациясын колдонуңуз (Java codeун колдонуу менен an objectтерди түзүү);
• Эң төмөнкү приоритеттүү жол - бул xml конфигурацияларын колдонуу менен эски модада.

Мындан тышкары, Жаз бул ыкмаларды айкалыштырууга мүмкүндүк берет. Мисалы, Spring автоматтык түрдө конфигурациялануучу нерселердин бардыгын аткарсын; кээ бир атайын параметрлерди көрсөтүү керек болсо, аны Java конфигурациялары аркылуу аткарыңыз жана андан тышкары, кээ бир эски конфигурацияларды xml форматында туташтыра аласыз. Жалпысынан алганда, мунун бардыгын ийкемдүү түрдө жасоого болот. Бирок баары бир автоматтык орнотууларды колдонуу менен жасалышы мүмкүн болсо, аны колдонуңуз. Мен автоматтык конфигурацияны жана Java конфигурацияларын гана карайм; xml конфигурациялары Интернеттеги дээрлик ар бир Жаз мисалында колдонулат жана Java конфигурациясынын кантип иштээрин түшүнгөндөн кийин, ошол эле нерсени аткарган xml файлын "окууда" эч кандай көйгөй болбойт. Автоматтык конфигурация жумушка керектүү an objectтер биз жазган класстардын an objectилери болгондо колдонулат . Эгерде биздин класстын an objectисин түзүү үчүн кандайдыр бир так логика керек болсо, же бизде автоматтык конфигурация тарабынан тандалып алынган annotation менен кандайдыр бир классты белгилөө мүмкүнчүлүгүбүз жок болсо, муну Java конфигурацияларында жасаса болот. . Кийинки бөлүктө биз maven долбоорун түзүп, ага бир нече борбордук жазгы модулдарды туташтырабыз жана биринчи буурчакыбызды түзөбүз.