Bahar tənbəllər üçündür. Əsaslar, əsas anlayışlar və kodla nümunələr. 1-ci hissə

Bir çox insanlar veb layihə üçün şablon yaratmaq və servletlərdən istifadə edərək sadə veb xidmət yaratmaq haqqında məqalələrimi oxuduqdan sonra Bahar haqqında nə vaxt yazacağımı düşündülər. İstəmədim, kitab oxumağı təklif etdim (və hələ də deyirəm ki, kitab internetdəki 10, hətta 100 məqalədən yaxşıdır). Ancaq indi qərara gəldim ki, eyni şeyi fərqli insanlara izah etmək üçün bir dəfə oturub məqalə yazmaqdansa, daha çox vaxt sərf edirəm, sonra sadəcə ona bir keçid yerləşdirdim. Ona görə də link xatirinə yazıram)). Bu yazıda öz nümunəmdən sonra 5 dəqiqə ərzində Baharda iş layihəsini necə edəcəyimi yazmayacağam. Mən yalnız əsas şeylər haqqında yazacağam, bunları bilmədən bir layihəyə başlamaq əlbəttə ki, mümkündür, amma orada nə baş verir və daha da vacibi, niyə aydın olmayacaq.

Spring Framework nədir?

Spring Framework və ya sadəcə olaraq Spring Java-da veb proqramlar yaratmaq üçün ən populyar çərçivələrdən biridir. Çərçivə kitabxanaya bənzər bir şeydir (bəlkə də bu termin sizə daha tanışdır), lakin bir məqam var. Təxminən desək, kitabxanadan istifadə etməklə siz sadəcə onun içindəki siniflərin obyektlərini yaradırsınız, sizə lazım olan metodları çağırır və bununla da sizə lazım olan nəticəni əldə edirsiniz. Yəni daha imperativ yanaşma var: proqramınızda aydın şəkildə göstərirsiniz ki, hansı konkret anda hansı obyekti yaratmalı, hansı anda konkret metodu çağırmalısınız və s. Çərçivələrlə hər şey bir az fərqlidir. Siz sadəcə olaraq öz siniflərinizdən bəzilərini yazın, məntiqin bir hissəsini ora yazın və çərçivə özü siniflərinizin obyektlərini yaradır və sizin üçün metodları çağırır. Çox vaxt sinifləriniz çərçivədən bəzi interfeysləri həyata keçirir və ya ondan bəzi sinifləri miras alır, beləliklə, artıq sizin üçün yazılmış bəzi funksiyaları alır. Amma bu belə olmamalıdır. Məsələn, Baharda onlar bu cür ciddi birləşmədən mümkün qədər uzaqlaşmağa çalışırlar (dərsləriniz birbaşa bu çərçivədəki bəzi siniflərdən/interfeyslərdən asılı olduqda) və bu məqsədlə annotasiyalardan istifadə edirlər. Bu məqama daha sonra qayıdacağıq. Ancaq başa düşmək lazımdır ki, Spring sadəcə sizin üçün artıq yazılmış bəzi siniflər və interfeyslər toplusudur :) Mən də dərhal qeyd etmək istəyirəm ki, Spring yalnız veb proqramlar üçün deyil, həm də ən çox yayılmış konsol üçün istifadə edilə bilər. hamımıza çox tanış olan proqramlar Və bu gün hətta buna bənzər bir şey yazacağıq.

Struktur

Ancaq Bahar xüsusi bir çərçivə deyil. Bu, hər biri bir növ fərqli iş görən bir sıra kiçik çərçivələrin ümumi adıdır. Gördüyünüz kimi, yay modul bir quruluşa malikdir. Bu, bizə yalnız tətbiqimiz üçün lazım olan modulları birləşdirməyə imkan verir və açıq-aydın istifadə etməyəcəyimiz modulları birləşdirməyə imkan verir. Bildiyimə görə, məhz bu yanaşma Baharın o zamankı rəqibini (EJB) üstələməsinə və liderlik etməsinə kömək etdi. Çünki EJB- dən istifadə edən proqramlar onlarla bir çox asılılıqlar çəkdi və ümumiyyətlə, yavaş və yöndəmsiz oldular. Şəkil göstərir ki, yay çərçivəsi bir neçə moduldan ibarətdir:

• məlumat əldə etmək;
• veb;
• əsas;
• və qeyriləri.

Bu gün biz əsas modulun bəzi anlayışları ilə tanış olacağıq, məsələn: lobya, kontekst və başqaları. Təxmin etdiyiniz kimi, məlumat giriş modulu məlumatlarla işləmək üçün alətləri (əsasən verilənlər bazası), veb - şəbəkədə işləmək üçün (o cümlədən daha sonra müzakirə ediləcək veb proqramların yaradılması üçün) ehtiva edir. Bundan əlavə, bütün Bahar infrastrukturu da var: rəsmi olaraq çərçivəyə daxil edilməyən, lakin Bahar layihənizə mükəmməl inteqrasiya olunan bir çox digər layihələr (məsələn, istifadəçi icazəsi ilə işləmək üçün eyni yay təhlükəsizliyi . sayt, inşallah nə vaxtsa biz də hiss edəcəyik).

Niyə Java-da Bahar?

Yaxşı, dəbli, qəşəng və gənc olması ilə yanaşı, dərhal deyə bilərəm ki, bir az da olsa mənimsəsən, indi nə qədər fərqli iş görməli olmadığını və nə qədər Bahar olduğunu anlayacaqsan. üzərinə götürür. Bir neçə onlarla sətir konfiqurasiya yaza, bir neçə sinif yaza bilərsiniz - və işləyən bir layihə əldə edəcəksiniz. Ancaq "başlıq altında" nə qədər şey olduğunu düşünməyə başlayan kimi, nə qədər iş görüldüyünü və eyni layihəni çılpaq servletlərdə və ya rozetkalarda və təmiz Java-da etsəniz, nə qədər kod yazılmalı idi. - saçın dikdir :) Hətta belə bir ifadə var, Baharın "sehrli"si kimi. Bu, hər şeyin işlədiyini görəndə, amma hər şeyin işləməsi üçün orada nə qədər baş verməli olduğunu və orada hər şeyin necə işlədiyini təxmini olaraq təxmin edirsən - o zaman bütün bunlar bir növ sehr sayəsində baş verir)) Bunu etmək daha asandır. bütün bunların bir-biri ilə necə əlaqəli olduğunu izah etməyə çalışmaqdansa, hamısını sehr adlandırın. gülümsəmək data_ web-mvc_ security_ sadəcə əsaslar.

DI/IoC

Baharda bir şey oxumağa çalışsanız, ilk rastlaşdığınız şey yəqin ki, bu hərflər olub: DI/IoC . İndi sizə bu məqaləyə fasilə verməyi və Habré-də bu məqaləni oxumağı çox tövsiyə edirəm ! IoC (İnversion of Control) - idarəetmənin inversiya edilməsi. Bunu yazarkən qeyd etdim ki, kitabxanadan istifadə edərkən hansı üsulla hansı obyekti çağıracağınızı kodunuza özünüz yazırsınız və çərçivələr vəziyyətində, əksər hallarda çərçivə sağda yazdığınız kodu çağırır. an. Yəni burada siz artıq kodun/proqramın icrası prosesinə nəzarət etmirsiniz, lakin çərçivə bunu sizin üçün edir. Siz nəzarəti ona verdiniz (nəzarətin inversiyası). DI ya Asılılığın İnversiyası (asılılığın inversiyası, yəni bir sinfin digərinə birbaşa bağlı olduğu modullarınız/sinifləriniz arasında sərt əlaqə yaratmamağa çalışır) və ya Asılılıq inyeksiyası (asılılıq inyeksiyası, bu, pişik obyektlərinin olmadığı zamandır) kimi başa düşülür. əsasda sizin tərəfinizdən yaradılmışdır və sonra siz onları öz metodlarınıza ötürəcəksiniz, Bahar isə onları sizin üçün yaradır və siz ona sadəcə olaraq “Mən burada bir pişik almaq istəyirəm” kimi bir şey söyləyirsiniz və o, metodunuzda sizə ötürür). Növbəti məqalələrdə ikinci ilə daha tez-tez qarşılaşacağıq.

Fasulye və kontekst

Yazda əsas anlayışlardan biri lobyadır . Əslində, o, sadəcə hansısa sinfin obyektidir . Tutaq ki, proqramımız üçün 3 obyektdən istifadə etməliyik: pişik, it və tutuquşu. Və bir dəstə metodu olan bir dəstə dərsimiz var, burada bəzən bir üsul üçün bir pişik və başqa bir üsul üçün bir it lazımdır və bəzən bir pişik və tutuquşuya ehtiyacımız olan üsullarımız olacaq (məsələn, bir üsul bir pişiyi qidalandırmaq üçün, hehe) və bəzi üsullarda hər üç obyektə ehtiyac olacaq. Bəli, biz əvvəlcə bu üç obyekti əsasda yarada bilərik, sonra isə onları siniflərimizə, siniflər içərisindən isə bizə lazım olan metodlara keçirə bilərik... Proqram boyu və s. Həm də təsəvvür etsək ki, vaxtaşırı metodlarımız üçün qəbul edilmiş parametrlərin siyahısını dəyişdirmək istəyirik (yaxşı, nəyisə yenidən yazmaq və ya funksionallıq əlavə etmək qərarına gəldik) - onda lazım olsa, koda kifayət qədər çox düzəliş etməli olacağıq. bir şeyi dəyişdirmək. İndi bizdə 3 yox, 300 belə obyektin olduğunu təsəvvür etsək necə olar? Alternativ olaraq bütün belə obyektlərimizi ümumi bir obyekt siyahısına ( List<Object> ) toplamaq və onu bütün metodlara ötürmək və metodların daxilindən bizə lazım olan bu və ya digər obyekti əldə etməkdir. Bəs proqram irəlilədikcə bu siyahıya hansısa obyektin əlavə oluna və ya (daha pisi) silinə biləcəyini təsəvvür etsək necə olar? Sonra siyahıdan obyektləri indeksinə görə çıxardığımız bütün üsullarda hər şey pozula bilər. Sonra siyahı deyil, xəritəni saxlamağa qərar veririk ki, burada açar bizə lazım olan obyektin adı, dəyəri isə obyektin özü olacaq və sonra biz ondan ehtiyac duyduğumuz obyektləri sadəcə adları ilə əldə edə bilərik. : get("tutuquşu") və cavab olaraq bir obyekt tutuquşu aldıq Yaxud, məsələn, açar obyektin sinfi, dəyər isə obyektin özüdür, onda biz artıq obyektin adını deyil, sadəcə olaraq bizə lazım olan obyektin sinfini göstərə bilərik ki, bu da əlverişlidir. Və ya hətta xəritənin üzərinə bir növ sarğı yazın, burada üsullar yarada bilərsiniz ki, bəzi hallarda obyektləri adlarına görə, digər hallarda isə sinifə görə əldə edə bilərsiniz. Yaz tətbiqi kontekstindən əldə etdiyimiz budur . Kontekst lobya (obyektlər) toplusudur. Kontekstə keçsək, bizə lazım olan paxlalı (obyekti) adı ilə, məsələn, növü ilə, yaxud başqa bir şeylə ala bilərik. Bundan əlavə, Bahardan ehtiyac duyduğumuz lobyanı kontekstində axtarmağı və metodumuza keçməsini xahiş edə bilərik. Məsələn, belə bir üsulumuz olsaydı:

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

Bahar bizim üçün bu üsulu çağıranda, pişiyimizin obyektini kontekstindən ona keçirdi. İndi qərara gəlirik ki, bizim metodumuza pişikdən əlavə tutuquşu da lazımdır. Bahardan istifadə - bizim üçün heç nə asan deyil! Sadəcə olaraq yazırıq:

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

Bahar isə bizim bu metodumuzu adlandıranda başa düşəcək ki, biz burada bir pişik və tutuquşu ötürməli, onun kontekstinə keçməliyik, bu iki obyekti əldə edib bizim metodumuza keçirməliyik. Proqramımızın cilovunu Bahara təhvil verməklə, obyektlərin yaradılması və onun çağıracağı metodlarımıza ötürülməsi məsuliyyətini də ona verdik. Sual yaranır: Bahar hansı obyektləri (zibil qutularını) yaratacağını necə biləcək?

Tətbiq Konfiqurasiya Metodları

Tətbiqi konfiqurasiya etməyin üç əsas yolu var (yəni Spring-ə hansı obyektləri işləməyimiz lazım olduğunu söyləyin):

1. xml faylları/konfiqurasiyalarından istifadə;
2. java konfiqurasiyalarından istifadə;
3. avtomatik konfiqurasiya.

Bahar tərtibatçıları onları bu prioritet ardıcıllıqla təşkil edirlər:

• üstünlük verilməli olan ən prioritet üsul avtomatik konfiqurasiyadır;
• avtomatik konfiqurasiyadan istifadə edərkən bütün mümkün lobyaları düzgün konfiqurasiya etmək mümkün deyilsə, Java konfiqurasiyasından istifadə edin (Java kodundan istifadə edərək obyektlərin yaradılması);
• Yaxşı, ən aşağı prioritet yol xml konfiqurasiyasından istifadə edərək köhnə üsuldur.

Bundan əlavə, Bahar bu üsulları birləşdirməyə imkan verir. Məsələn, Spring-ə avtomatik olaraq konfiqurasiya edilə bilən hər şeyi etməyə icazə verin; bəzi xüsusi parametrləri təyin etməli olduğunuz yerdə bunu Java konfiqurasiyasından istifadə edərək edin və əlavə olaraq bəzi köhnə konfiqurasiyaları xml formatında birləşdirə bilərsiniz. Ümumiyyətlə, bütün bunlar kifayət qədər çevik şəkildə edilə bilər. Ancaq yenə də hər şeyi avtomatik parametrlərdən istifadə etməklə etmək olarsa, ondan istifadə edin. Mən yalnız avtomatik konfiqurasiya və Java konfiqurasiyalarını nəzərdən keçirəcəyəm; xml konfiqurasiyaları artıq İnternetdə demək olar ki, hər bir Bahar nümunəsində istifadə olunur və Java konfiqurasiyasının necə işlədiyini başa düşdükdən sonra, eyni şeyi edən xml faylını “oxumaq” problemi olmamalıdır. Avtomatik konfiqurasiya iş üçün lazım olan obyektlər yazdığımız siniflərin obyektləri olduqda istifadə olunur . Sinifimizin obyektini yaratmaq üçün çox spesifik məntiq tələb olunarsa və ya hansısa sinfi avtomatik konfiqurasiya tərəfindən seçilən bizə lazım olan annotasiya ilə qeyd etmək imkanımız yoxdursa, bu, Java konfiqurasiyasında edilə bilər. . Növbəti hissədə bir maven layihəsi yaradacağıq, ona bir neçə mərkəzi yay modulunu bağlayacağıq və ilk lobyamızı yaradacağıq.