Көктем жалқауларға арналған. Негіздер, негізгі түсініктер және кодпен мысалдар. 1 бөлім

Көптеген адамдар менің веб-жобаға үлгі жасау және сервлеттерді пайдаланып қарапайым веб-қызмет жасау туралы мақалаларымды оқығаннан кейін көктем туралы қашан жазамын деп ойлады. Мен қаламадым, мен кітап оқуды ұсындым (және мен әлі күнге дейін Интернеттегі 10, тіпті 100 мақаладан да кітап жақсы деп айтамын). Бірақ қазір мен әр түрлі адамдарға бірдей нәрсені түсіндіру үшін бір рет отырып, мақала жазып, содан кейін оған сілтеме жібергеннен гөрі көбірек уақыт жұмсаймын деп шештім. Сондықтан мен сілтеме үшін жазып отырмын)). Бұл мақалада мен мысалға 5 minutes ішінде көктемде жұмыс жобасын қалай жасау керектігін жазбаймын. Мен тек негізгі нәрселер туралы жазамын, оны білмей-ақ жобаны бастауға болады, бірақ ол жерде не болып жатқаны және одан да маңыздысы неге екені белгісіз.

Spring Framework дегеніміз не?

Spring Framework немесе жай ғана Spring - Java-да веб-қосымшаларды жасауға арналған ең танымал фреймворктардың бірі. Фреймворк кітапханаға ұқсас нәрсе (мүмкін бұл термин сізге көбірек таныс), бірақ бір тармақ бар. Бір сөзбен айтқанда, кітапхананы пайдалана отырып, сіз жай ғана ондағы сыныптардың an objectілерін жасайсыз, қажетті әдістерді шақырасыз және осылайша қажетті нәтиже аласыз. Яғни, анағұрлым императивті тәсіл бар: сіз өзіңіздің бағдарламаңызда қандай нақты сәтте қандай нысанды жасау керектігін, қандай сәтте нақты әдісті шақыру керектігін және т.б. нақты көрсетесіз. Фреймворктармен бәрі біршама ерекшеленеді. Сіз жай ғана өзіңіздің кейбір сыныптарыңызды жазасыз, логиканың бір бөлігін сол жерге жазасыз, ал рамканың өзі сыныптарыңыздың нысандарын жасайды және сіз үшін әдістерді шақырады. Көбінесе сіздің сыныптарыңыз фреймворктен кейбір интерфейстерді жүзеге асырады немесе одан кейбір сыныптарды мұраға алады, осылайша сіз үшін бұрыннан жазылған кейбір функцияларды алады. Бірақ олай болуы шарт емес. Мысалы, көктемде олар мұндай қатаң байланыстан мүмкіндігінше алыстауға тырысады (сыныптарыңыз осы шеңбердегі кейбір сыныптарға/интерфейстерге тікелей тәуелді болғанда) және осы мақсат үшін annotationларды пайдаланады. Бұл мәселеге кейінірек ораламыз. Бірақ Spring - бұл сіз үшін жазылған кейбір сыныптар мен интерфейстердің жиынтығы екенін түсіну маңызды :) бәрімізге таныс бағдарламалар Ал бүгін біз тіпті осындай нәрсені жазамыз.

Құрылым

Бірақ көктем - бұл белгілі бір шеңбер емес. Бұл әрқайсысы әртүрлі жұмыстарды атқаратын бірнеше шағын фреймворктардың жалпы атауы. Көріп отырғаныңыздай, серіппенің модульдік құрылымы бар. Бұл бізге қолданбамызға қажет модульдерді ғана қосуға мүмкіндік береді және біз анық пайдаланbyteын модульдерді қоспай аламыз. Менің білуімше, көктемнің сол кездегі бәсекелесінен (EJB) асып түсуіне және көшбасшылыққа ие болуына осы тәсіл көмектесті. Өйткені EJB қолданатын қосымшалар олармен бірге көптеген тәуелділіктерді алып тастады және жалпы олар баяу және ебедейсіз болып шықты. Суретте серіппелі жақтаудың бірнеше модульдерден тұратыны көрсетілген:

• деректерге қол жеткізу;
• желі;
• негізгі;
• және басқалар.

Бүгін біз негізгі модульдің кейбір ұғымдарымен танысамыз, мысалы: бұршақ, контекст және т.б. Сіз болжағандай, деректерге қол жеткізу модулінде деректермен жұмыс істеуге арналған құралдар (негізінен дерекқорлар), желіде жұмыс істеу үшін (соның ішінде кейінірек талқыланатын веб-қосымшаларды жасау үшін) бар. Бұған қоса, бүкіл көктемгі инфрақұрылым деп аталатындар да бар: рамканың өзінде ресми түрде қосылмаған, бірақ көктемгі жобаңызға үздіксіз біріктірілген көптеген басқа жобалар (мысалы, пайдаланушы авторизациясымен жұмыс істеу үшін бірдей көктемгі қауіпсіздік . сайт, оны біз де бір күні сезінеміз деп үміттенемін).

Неліктен Java-дағы көктем?

Сәнді, сәнді және жастыққа сай келетінін айтпағанда, оны аздап игеріп алсаңыз, қазір қаншама түрлі жұмыс істеудің қажеті жоқ екенін және көктемнің қаншалықты көп екенін түсінесіз деп бірден айта аламын. қабылдайды. Сіз конфигурацияның бірнеше ондаған жолын жаза аласыз, бірнеше класс жаза аласыз - және сіз жұмыс жобасын аласыз. Бірақ сіз «қақпақтың астында» қанша нәрсе бар екендігі туралы ойлай бастағанда, қанша жұмыс жасалып жатыр және егер сіз бірдей жобаны жалаң сервлеттерде немесе ұяшықтарда және таза Java-да жасасаңыз, қанша code жазылуы керек еді. - шашың тік тұрады :) Тіпті Көктемнің «сиқыры» сияқты осындай өрнек бар. Міне, сіз бәрі жұмыс істеп тұрғанын көргенде, бірақ бәрі жұмыс істеуі үшін ол жерде қанша болуы керек екенін және оның қалай жұмыс істейтінін шамамен есептейсіз - сонда мұның бәрі қандай да бір сиқырдың арқасында болып жатқан сияқты)) Бұл оңайырақ Мұның бәрі бір-бірімен қалай байланысты екенін түсіндіруге тырысқаннан гөрі, мұны сиқыр деп атаңыз. күлімсіреу data_ web-mvc_ security_ жай ғана негізгі.

DI/IoC

Егер сіз Көктемде бірдеңе оқуға тырыссаңыз, сіз бірінші кезекте мына әріптерді кездестірген боларсыз: DI/IoC . Енді мен сізге осы мақаладан үзіліс жасап, Хабредегі осы мақаланы оқып шығуды ұсынамын ! IoC (Inversion of Control) – басқарудың инversionсы. Кітапхананы пайдаланған кезде сіз өзіңіздің codeыңызға қай нысанды шақыру әдісін өзіңіз жазасыз, ал фреймворк жағдайында көбінесе оң жақта жазған codeты фреймворк шақырады деп жазғанымда бұл туралы айтып өткен едім. сәт. Яғни, мұнда сіз codeты/бағдарламаны орындау процесін басқара алмайсыз, бірақ фреймворк оны сіз үшін жасайды. Сіз оған басқаруды тапсырдыңыз (басқарудың инversionсы). DI Тәуелділік инversionсы (тәуелділік инversionсы, яғни бір класс екіншісіне тікелей байланысты модульдер/сыныптар арасында қатты байланыстарды жасамауға тырысады) немесе тәуелділік инъекциясы (тәуелділік инъекциясы, бұл мысық нысандары болмаған кезде) деп түсініледі. Сіз негізінен өзіңіз жасаған, содан кейін сіз оларды әдістеріңізге бересіз, ал Көктем оларды сіз үшін жасайды, сіз оған жай ғана «Мен мұнда мысық алғым келеді» деген сияқты нәрсені айтасыз, ол сіздің әдісіңізде оны сізге береді). Біз келесі мақалаларда екіншісін жиі кездестіреміз.

Бұршақ және контекст

Көктемдегі негізгі ұғымдардың бірі - бұршақ . Негізінде бұл қандай да бір сыныптың an objectісі ғана. Біздің бағдарламамыз үшін 3 нысанды пайдалануымыз керек делік: мысық, ит және тотықұс. Ал бізде әдіс-тәсілдері бар көптеген сабақтар бар, мұнда кейде әдіс үшін мысық, ал басқа әдіс үшін ит қажет, ал кейде бізге мысық пен тотықұс қажет болатын әдістер болады (мысалы, әдіс мысықты тамақтандыру үшін, хехе) және кейбір әдістерде барлық үш нысан қажет болады. Иә, біз алдымен осы үш нысанды негізгі түрде жасай аламыз, содан кейін оларды өз сыныптарымызға, ал сыныптардың ішінен бізге қажетті әдістерге көшіре аламыз ... Бағдарламаның ішінде және т.б. Егер біз өз әдістеріміз үшін қабылданған параметрлердің тізімін мезгіл-мезгіл өзгерткіміз келетінін елестетсек (жақсы, біз бірдеңені қайта жазуды немесе функционалдылықты қосуды шештік) - егер қажет болса, codeқа көптеген түзетулер енгізуге тура келеді. бір нәрсені өзгерту. Енді бізде мұндай 3 емес, 300 нысан бар деп елестетсек ше? Балама - біздің барлық осындай нысандарды an objectілердің бір жалпы тізіміне ( List<Object> ) жинау және оны барлық әдістерге беру және әдістер ішінен бізге қажет осы немесе басқа нысанды алу. Бірақ егер бағдарлама дамып келе жатқанда, бұл тізімге қандай да бір нысан қосылуы немесе (не сорақысы) жойылуы мүмкін деп елестетсек ше? Содан кейін тізімнен an objectілерді индексі бойынша шығаратын барлық әдістерде бәрі бұзылуы мүмкін. Содан кейін біз тізімді емес, картаны сақтауды шешеміз, мұнда кілт бізге қажетті нысанның атауы болады, ал мән нысанның өзі болады, содан кейін біз одан қажетті нысандарды жай ғана олардың атымен ала аламыз. : get("parrot") және жауап ретінде біз тотықұс нысанын алдық Немесе, мысалы, кілт нысанның класы, ал мән an objectінің өзі болса, онда біз енді an objectінің атын емес, жай ғана бізге қажет an objectінің класын көрсете аламыз, бұл да ыңғайлы. Немесе тіпті картаның үстіне қандай да бір қаптаманы жазыңыз, онда сіз кейбір жағдайларда нысандарды олардың аты бойынша, ал басқа жағдайларда сынып бойынша шығарып алуға болатын әдістерді жасай аласыз. Бұл көктемгі қолданба контекстінен алатынымыз . Мәтінмән - бұл бұршақтардың (нысандардың) жиынтығы. Мәтінмәнге жүгінсек, бізге қажет бұршақты (an objectіні) оның аты бойынша, мысалы, түрі бойынша немесе басқа нәрсе бойынша алуға болады. Сонымен қатар, біз Көктемнен бізге қажет бұршақты оның контекстінде іздеуді және оны біздің әдісімізге беруді сұрай аламыз. Мысалы, егер бізде осындай әдіс болса:

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

Көктем бұл әдісті біз үшін шақырғанда, ол біздің мысықтың an objectісін контекстен оған берді. Енді біздің әдіске мысықтан басқа попуга да қажет деп шештік. Көктемді пайдалану - біз үшін оңай ештеңе жоқ! Біз жай ғана жазамыз:

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

ал Көктем біздің бұл әдісімізді атағанда, мұнда мысық пен тотықұсты өткізіп, оның контекстіне өтіп, осы екі нысанды алып, оларды әдісімізге беру керек екенін түсінеді. Бағдарламамыздың тізгінін Көктемге тапсыра отырып, біз оған нысандарды жасау және оларды ол шақыратын әдістерімізге беру жауапкершілігін де тапсырдық. Сұрақ туындайды: көктем қандай нысандарды (қоқыс жәшіктерін) жасау керектігін қайдан біледі?

Қолданбаны конфигурациялау әдістері

Қолданбаны конфигурациялаудың үш негізгі жолы бар (яғни, Spring-ке қандай нысандармен жұмыс істеу керектігін айтыңыз):

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

Көктемгі әзірлеушілер оларды осы басымдық ретімен реттейді:

• артықшылық беру керек ең басым әдіс - автоматты конфигурация;
• егер автоматты конфигурацияны пайдалансаңыз, барлық ықтимал бұршақтарды дұрыс конфигурациялау мүмкін болмаса, Java конфигурациясын пайдаланыңыз (Java codeын пайдаланып нысандарды жасау);
• Ең төменгі басымдықты әдіс - xml конфигурацияларын қолданатын ескі әдіс.

Сонымен қатар, көктем осы әдістерді біріктіруге мүмкіндік береді. Мысалы, Spring-ке автоматты түрде конфигурацияланатын барлық нәрсені жасауға рұқсат етіңіз; кейбір арнайы параметрлерді көрсету қажет болса, оны Java конфигурациялары арқылы орындаңыз және оған қоса, кейбір бұрынғы конфигурацияларды xml пішімінде қосуға болады. Жалпы, мұның барлығын икемді түрде жасауға болады. Дегенмен, бәрі автоматты параметрлерді пайдаланып жасалса, оны пайдаланыңыз. Мен тек автоматты конфигурацияны және Java конфигурацияларын қарастырамын; xml конфигурациялары Интернеттегі әрбір дерлік көктем мысалында қолданылған және Java конфигурациясының қалай жұмыс істейтінін түсінгеннен кейін, бірдей нәрсені жасайтын xml файлын «оқуда» ешқандай қиындық болмауы керек. Автоматты конфигурация жұмыс үшін қажет an objectілер біз жазған сыныптардың an objectілері болған кезде қолданылады . Егер біздің сыныптың an objectісін жасау үшін өте нақты логика қажет болса немесе бізде автоматты конфигурациямен таңдалатын кейбір классты қажет annotationмен белгілеу мүмкіндігі болмаса, мұны Java конфигурацияларында жасауға болады. . Келесі бөлімде біз maven жобасын жасаймыз, оған бірнеше орталық серіппелі модульдерді қосамыз және алғашқы бұршақтарды жасаймыз.