Wiosna jest dla leniwych. Podstawy, podstawowe pojęcia i przykłady z kodem. Część 1

Wiele osób po przeczytaniu moich artykułów na temat tworzenia szablonu projektu internetowego i tworzenia prostej usługi internetowej za pomocą serwletów zastanawiało się, kiedy napiszę o Springu. Nie chciałam, zasugerowałam przeczytanie książki (i nadal twierdzę, że książka jest lepsza niż 10, a nawet 100 artykułów w Internecie). Ale teraz doszedłem do wniosku, że tłumacząc to samo różnym osobom, poświęcę więcej czasu, niż gdybym raz usiadł i napisał artykuł, a potem po prostu zamieścił do niego link. Więc piszę dla linku)). W tym artykule nie będę pisał, jak zrobić działający projekt na wiosnę w 5 minut, kierując się moim przykładem. Napiszę tylko o podstawowych rzeczach, bez znajomości których z pewnością można rozpocząć projekt, ale co się tam dzieje i, co ważniejsze, dlaczego, nie będzie jasne.

Co to jest Spring Framework?

Spring Framework , czyli po prostu Spring , to jeden z najpopularniejszych frameworków do tworzenia aplikacji internetowych w Javie. Framework jest czymś podobnym do biblioteki (być może ten termin jest ci bardziej znany), ale jest jeden punkt. Z grubsza mówiąc, korzystając z biblioteki, po prostu tworzysz obiekty klas, które się w niej znajdują, wywołujesz potrzebne metody i w ten sposób uzyskujesz potrzebny wynik. Oznacza to, że istnieje bardziej imperatywne podejście: wyraźnie wskazujesz w swoim programie, w którym konkretnym momencie musisz utworzyć jaki obiekt, w którym momencie musisz wywołać konkretną metodę itp. W przypadku frameworków sytuacja wygląda nieco inaczej. Po prostu piszesz kilka własnych klas, wpisujesz tam część logiki, a sam framework tworzy obiekty twoich klas i wywołuje za ciebie metody. Najczęściej Twoje klasy implementują jakieś interfejsy z frameworka lub dziedziczą po nim część klas, otrzymując w ten sposób część funkcjonalności już dla Ciebie napisanych. Ale to nie musi tak być. Na przykład wiosną starają się jak najbardziej odejść od tak ścisłego łączenia (kiedy twoje klasy bezpośrednio zależą od niektórych klas/interfejsów z tego frameworka) i używają w tym celu adnotacji. Wrócimy do tego punktu później. Ale ważne jest, aby zrozumieć, że Spring to tylko zestaw niektórych klas i interfejsów, które zostały już dla Ciebie napisane :) Chcę też od razu zaznaczyć, że Spring może być używany nie tylko w aplikacjach internetowych, ale także w najpopularniejszej konsoli aplikacje, które są tak dobrze znane każdemu z nas programy A dzisiaj nawet coś takiego napiszemy.

Struktura

Ale Spring nie jest jednym konkretnym frameworkiem. Jest to raczej ogólna nazwa kilku małych frameworków, z których każdy wykonuje inną pracę. Jak widać sprężyna ma budowę modułową. Dzięki temu możemy podłączyć tylko te moduły, które są nam potrzebne do naszej aplikacji i nie podłączać tych, z których oczywiście nie będziemy korzystać. O ile wiem, to właśnie takie podejście pomogło Springowi wyprzedzić ówczesnego konkurenta (EJB) i objąć prowadzenie. Ponieważ aplikacje korzystające z EJB ściągały ze sobą wiele zależności i ogólnie okazywały się powolne i niezgrabne. Obraz pokazuje, że framework wiosenny składa się z kilku modułów:

• dostęp do danych;
• sieć;
• rdzeń;
• i inni.

Dziś zapoznamy się z niektórymi pojęciami modułu głównego, takimi jak: fasola, kontekst i inne. Jak można się domyślić, moduł dostępu do danych zawiera narzędzia do pracy z danymi (głównie bazami danych), web - do pracy w sieci (m.in. do tworzenia aplikacji internetowych, o czym będzie mowa później). Ponadto istnieje również tak zwana cała infrastruktura Spring: wiele innych projektów, które nie są oficjalnie uwzględnione w samym frameworku, ale są płynnie zintegrowane z Twoim projektem Spring (na przykład to samo wiosenne zabezpieczenie do pracy z autoryzacją użytkownika na miejscu, co, mam nadzieję, my też kiedyś odczujemy).

Dlaczego wiosna w Javie?

No cóż, poza tym, że jest modnie, stylowo i młodzieżowo, to od razu mogę powiedzieć, że jak tylko choć trochę opanujesz to zrozumiesz, ile innej pracy już nie musisz wykonywać, a ile wiosny przyjmuje. Możesz napisać kilkadziesiąt linii konfiguracji, napisać kilka klas - a otrzymasz działający projekt. Ale gdy tylko zaczniesz myśleć o tym, ile jest „pod maską”, ile pracy jest w toku i ile kodu trzeba by napisać, gdybyś zrobił ten sam projekt na gołych serwletach lub na gniazdach i czystej Javie - włosy stają dęba :) Jest nawet takie określenie, jak "magia" wiosny. To wtedy widzisz, że wszystko działa, ale z grubsza szacujesz, ile musi się tam wydarzyć, żeby wszystko zadziałało i jak tam wszystko działa - wtedy wydaje się, że to wszystko dzieje się naprawdę dzięki jakiejś magii)) Łatwiej jest nazwać to wszystko magią, niż próbować wyjaśnić, jak to wszystko jest ze sobą powiązane. :) Otóż drugim argumentem „za” nauką Wiosny jest to, że w około 90% wolnych miejsc dla juniora (według moich osobistych obserwacji) albo wiedza, albo chociaż ogólne pojęcie o męskim zestawie Wiosny z data, web-mvcoraz security:) wymagane są tylko podstawy.

DI/IoC

Jeśli próbowałeś przeczytać coś na temat Springa, pierwszą rzeczą, na którą się natknąłeś, były prawdopodobnie te litery: DI/IoC . Teraz gorąco polecam zrobić sobie przerwę od tego artykułu i przeczytać ten artykuł na temat Habré ! IoC (Inversion of Control) - odwrócenie kontroli. Wspomniałem już o tym na marginesie, gdy pisałem, że korzystając z biblioteki, sam wpiszesz w swoim kodzie, jaką metodę jaki obiekt wywołać, a w przypadku frameworków najczęściej framework wywoła kod, który napisałeś po prawej stronie za chwilę. Oznacza to, że tutaj nie kontrolujesz już procesu wykonywania kodu/programu, ale framework robi to za Ciebie. Przekazałeś mu kontrolę (odwrócenie kontroli). DI jest rozumiane jako inwersja zależności (inwersja zależności, to znaczy próba nie tworzenia twardych połączeń między modułami/klasami, gdzie jedna klasa jest bezpośrednio powiązana z inną) lub wstrzykiwanie zależności (wstrzykiwanie zależności, ma to miejsce, gdy obiekty cat nie są utworzone przez ciebie głównie, a następnie przekazujesz je do swoich metod, a Spring tworzy je dla ciebie, a ty po prostu mówisz mu coś w stylu „Chcę tu dostać kota”, a on przekazuje ci to w twojej metodzie). Z tym drugim będziemy częściej spotykać się w kolejnych artykułach.

Fasola i kontekst

Jednym z kluczowych pojęć na wiosnę jest fasola . W istocie jest to po prostu obiekt pewnej klasy. Załóżmy, że w naszym programie potrzebujemy 3 obiektów: kota, psa i papugi. Mamy też kilka klas z wieloma metodami, gdzie czasami potrzebujemy kota do metody i psa do innej metody, a czasami będziemy mieć metody, do których potrzebujemy kota i papugi (na przykład metoda do karmienia kota, hehe), a w niektórych metodach potrzebne będą wszystkie trzy obiekty. Tak, możemy najpierw utworzyć te trzy obiekty w głównej części, a następnie przekazać je naszym klasom, a następnie z klas do potrzebnych nam metod... I tak dalej w trakcie programu. A jeśli także wyobrazimy sobie, że okresowo będziemy chcieli zmienić listę akceptowanych parametrów dla naszych metod (no cóż, postanowiliśmy coś przepisać lub dodać funkcjonalność) - to będziemy musieli dokonać całkiem sporo zmian w kodzie, jeśli zajdzie taka potrzeba Zmień coś. A co jeśli wyobrazimy sobie, że mamy nie 3, ale 300 takich obiektów? Alternatywą jest zebranie wszystkich naszych obiektów w jedną wspólną listę obiektów ( List<Object> ) i przekazanie jej do wszystkich metod, a z wnętrza metod pozyskujemy ten lub inny obiekt, którego potrzebujemy. Co jednak, jeśli wyobrazimy sobie, że w miarę postępu programu jakiś obiekt może zostać dodany do tej listy lub (co gorsza) usunięty? Wtedy we wszystkich metodach, w których pobieramy obiekty z listy po ich indeksie, wszystko może się zepsuć. Następnie decydujemy się na przechowywanie nie listy, ale mapy, gdzie kluczem będzie nazwa potrzebnego nam obiektu, a wartością będzie sam obiekt i wtedy będziemy mogli pobrać z niego potrzebne nam obiekty po prostu według ich nazwy : get("parrot") i w odpowiedzi otrzymaliśmy obiekt papuga Albo np. kluczem jest klasa obiektu, a wartością sam obiekt, wtedy nie możemy już wskazać nazwy obiektu, a po prostu potrzebną nam klasę obiektu, co też jest wygodne. Lub nawet napisz na mapie jakiś rodzaj opakowania, w którym możesz utworzyć metody, dzięki którym w niektórych przypadkach będziesz mógł pobierać obiekty według ich nazwy, a w innych przypadkach według klasy. To właśnie otrzymujemy z kontekstu aplikacji wiosennej . Kontekst to zbiór ziaren (obiektów). Wracając do kontekstu, możemy uzyskać potrzebną fasolę (obiekt), na przykład po nazwie, typie lub czymś innym. Dodatkowo możemy poprosić Springa, aby poszukał potrzebnego nam komponentu bean w swoim kontekście i przekazał go naszej metodzie. Na przykład, gdybyśmy mieli taką metodę:

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

Kiedy Spring wywołał dla nas tę metodę, przekazał do niego obiekt naszego kota z kontekstu. Teraz decydujemy, że do naszej metody oprócz kota potrzebna jest także papuga. Korzystanie z wiosny - nie ma dla nas nic prostszego! Po prostu piszemy:

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

a Spring, gdy wywoła tę naszą metodę, zrozumie, że musimy przekazać tutaj kota i papugę, przejść do ich kontekstu, pobrać te dwa obiekty i przekazać je naszej metodzie. Oddając stery naszego programu Springowi, przekazaliśmy mu także odpowiedzialność za tworzenie obiektów i przekazywanie ich naszym metodom, które będzie nazywał. Powstaje pytanie: skąd Spring będzie wiedział, które obiekty (pojemniki) utworzyć?

Metody konfiguracji aplikacji

Istnieją trzy główne sposoby konfiguracji aplikacji (czyli poinformowania Springa, z którymi obiektami mamy pracować):

1. używanie plików/konfiguracji xml;
2. używanie konfiguracji Java;
3. konfiguracja automatyczna.

Programiści Springa układają je w następującej kolejności:

• najbardziej priorytetową metodą, którą należy preferować, jest konfiguracja automatyczna;
• jeśli korzystasz z konfiguracji automatycznej nie jest możliwe poprawne skonfigurowanie wszystkich możliwych komponentów bean, użyj konfiguracji Java (tworzenie obiektów przy użyciu kodu Java);
• Cóż, sposobem o najniższym priorytecie jest staromodny sposób, wykorzystujący konfiguracje XML.

Ponadto Spring umożliwia łączenie tych metod. Na przykład pozwól Springowi zrobić wszystko, co można skonfigurować automatycznie; jeśli musisz określić jakieś specjalne parametry, zrób to przy użyciu konfiguracji Java, a ponadto możesz podłączyć niektóre starsze konfiguracje w formacie XML. Ogólnie rzecz biorąc, wszystko to można zrobić dość elastycznie. Ale nadal, jeśli wszystko można zrobić przy użyciu ustawień automatycznych, użyj go. Rozważę tylko konfigurację automatyczną i konfiguracje Java; konfiguracje xml są już używane w prawie każdym przykładzie wiosny w Internecie, a kiedy zrozumiesz, jak działa konfiguracja Java, nie powinno być problemu z „odczytaniem” pliku xml, który robi to samo. Konfigurację automatyczną stosujemy wtedy, gdy obiektami potrzebnymi nam do pracy są obiekty napisanych przez nas klas . Jeśli do utworzenia obiektu naszej klasy potrzebna jest bardzo specyficzna logika lub jeśli nie mamy możliwości oznaczenia klasy potrzebną adnotacją, która zostałaby wychwycona przez automatyczną konfigurację, można to zrobić w konfiguracjach Java . W kolejnej części stworzymy projekt mavenowy, podłączymy do niego kilka centralnych modułów sprężynowych i stworzymy naszą pierwszą fasolę.