Пролет за мързеливи хора Основа, основни концепции и примери с код. Част 1

В тази статия няма да ви казвам How да стартирате работещ Spring проект за 5 minutesи, като използвате моя code. Ще напиша само основите — неща, за които може да сте невежи и въпреки това да създадете проект. Но в тази статия все още няма да разберете Howво се случва и, което е по-важно, защо.

Какво представлява пролетната рамка?

Spring Framework or просто Spring е една от най-популярните рамки за създаване на уеб applications в Java. Рамката е като библиотека (може би сте по-запознати с този термин), но има Howво да имате предвид. Грубо казано, когато използвате библиотека, вие просто създавате екземпляри на класовете, които тя съдържа, извиквате методите, от които се нуждаете, и по този начин получавате желания резултат. С други думи, това е по-наложителен подход: във вашата програма вие изрично посочвате конкретния момент, когато трябва да създадете кой обект, кога да извикате кой конкретен метод и т.н. При фреймворковете нещата са малко по-различни. Вие просто пишете някои ваши собствени класове и записвате няHowва логика в тях, но след това самата рамка създава екземпляри на вашите класове и извиква техните методи. Вашите класове обикновено имплементират някои интерфейси от рамката or наследяват някои от нейните класове, като по този начин ви предоставят някои функции, които вече са написани за вас. Но това не винаги е така. Например, Spring се опитва колкото е възможно повече да избегне такова тясно свързване (където вашите класове директно зависят от класове/интерфейси в рамката). Той използва анотации, за да постигне това. Ще се върнем към това по-късно. Но е важно да разберете, че Spring е просто колекция от класове и интерфейси, които можете да използвате :) Също така искам да отбележа веднага, че Spring може да се използва не само за уеб applications, но и за най-често срещаните конзолни програми които са толкова познати на всички ни. И ние дори ще напишем един от тях днес. като по този начин ви предоставя някои функции, които вече са написани за вас. Но това не винаги е така. Например, Spring се опитва колкото е възможно повече да избегне такова тясно свързване (където вашите класове директно зависят от класове/интерфейси в рамката). Той използва анотации, за да постигне това. Ще се върнем към това по-късно. Но е важно да разберете, че Spring е просто колекция от класове и интерфейси, които можете да използвате :) Също така искам да отбележа веднага, че Spring може да се използва не само за уеб applications, но и за най-често срещаните конзолни програми които са толкова познати на всички ни. И ние дори ще напишем един от тях днес. като по този начин ви предоставя някои функции, които вече са написани за вас. Но това не винаги е така. Например, Spring се опитва колкото е възможно повече да избегне такова тясно свързване (където вашите класове директно зависят от класове/интерфейси в рамката). Той използва анотации, за да постигне това. Ще се върнем към това по-късно. Но е важно да разберете, че Spring е просто колекция от класове и интерфейси, които можете да използвате :) Също така искам да отбележа веднага, че Spring може да се използва не само за уеб applications, но и за най-често срещаните конзолни програми които са толкова познати на всички ни. И ние дори ще напишем един от тях днес. Spring се опитва колкото е възможно повече да избегне такова тясно свързване (където вашите класове директно зависят от класове/интерфейси в рамката). Той използва анотации, за да постигне това. Ще се върнем към това по-късно. Но е важно да разберете, че Spring е просто колекция от класове и интерфейси, които можете да използвате :) Също така искам да отбележа веднага, че Spring може да се използва не само за уеб applications, но и за най-често срещаните конзолни програми които са толкова познати на всички ни. И ние дори ще напишем един от тях днес. Spring се опитва колкото е възможно повече да избегне такова тясно свързване (където вашите класове директно зависят от класове/интерфейси в рамката). Той използва анотации, за да постигне това. Ще се върнем към това по-късно. Но е важно да разберете, че Spring е просто колекция от класове и интерфейси, които можете да използвате :) Също така искам да отбележа веднага, че Spring може да се използва не само за уеб applications, но и за най-често срещаните конзолни програми които са толкова познати на всички ни. И ние дори ще напишем един от тях днес. ) Също така искам веднага да отбележа, че Spring може да се използва не само за уеб applications, но и за най-често срещаните конзолни програми, които са толкова познати на всички нас. И ние дори ще напишем един от тях днес. ) Също така искам веднага да отбележа, че Spring може да се използва не само за уеб applications, но и за най-често срещаните конзолни програми, които са толкова познати на всички нас. И ние дори ще напишем един от тях днес.

Структура

Но пролетта не е само една конкретна рамка. По-скоро това е често срещано име, използвано за обозначаване на няколко малки рамки, всяка от които върши свой собствен вид работа.

https://docs.spring.io/spring/docs/4.3.26.RELEASE/spring-framework-reference/htmlsingle/
Фигура 2.1. Преглед на Spring Framework

Както можете да видите, Spring е модулен. Това ни позволява да свързваме само модулите, от които се нуждаем за нашето приложение, и да не свързваме тези, които очевидно няма да използваме. Доколкото знам, именно този подход позволи на Spring да надмине тогавашния си конкурент (EJB) и да поеме лидерството. Приложенията, използващи EJB , влачат много зависимости зад себе си и в резултат на това се оказват мудни и бавни. Изображението показва, че Spring Framework се състои от няколко модула:

• Достъп до данни
• Мрежа
• Ядро
• и още

Днес ще се запознаем с някои понятия, намиращи се в основния модул: beans, контекст и други. Както може би се досещате, модулът Data Access съдържа инструменти за работа с данни (основно бази данни), а Web модулът е за работа в мрежа (включително създаване на уеб applications, за които ще стане дума по-късно). Освен това има цялостна инфраструктура, която поддържа Spring: много други проекти, които не са официално включени в самата рамка, но са безпроблемно интегрирани във вашия Spring проект (например Spring Security, който също се надявам да засегна, е за удостоверяване на потребител на уебсайт).

Защо Java има Spring Framework?

Е, освен факта, че е модерен, гладък и свеж, мога да кажа веднага, че веднага щом придобиете дори малко умение да използвате Spring, ще разберете How има всяHowви видове работа, които вече нямате за вършене и колко работа поема пролетта. Можете да напишете няколко дузини реда с конфигурационни настройки и да напишете няколко класа и в крайна сметка ще получите работещ проект. Но веднага щом започнете да се чудите колко неща има под капака, колко работа се върши и колко code ще трябва да напишете, ако възнамерявате да внедрите един и същ проект, базиран на обикновени сървлети or сокети и чиста Java, ще ти настръхнат косите :) Пролетта даже я описват като няHowва магия. Изпитвате това, когато видите, че всичко работи, но също така имате груба представа How и колко работа се случва зад кулисите — така че изглежда, че наистина има няHowва магия в действие :) По-лесно е да я наречем магия, отколкото да се опитваме да обясним How всичко е взаимосвързано. :) Вторият аргумент в полза на изучаването на Spring е, че приблизително 90% от свободните работни места за младши разработчици (въз основа на моите лични наблюдения) изискват or познаване, or поне обща представа за това Howво е SpringData, Web MVC, и Securityмодулите предлагат сложни разработчици :) Но днес е само за основите.

DI/IoC

Ако някога сте опитвали да четете за пролетта, тогава първото нещо, което сте срещнали, вероятно са бor тези акроними: DI/IoC. Сега горещо ви препоръчвам да си починете от тази статия и да прочетете тази статия на DZone ! IoC означава инversion на контрола. Вече споменах това мимоходом, когато писах, че използването на библиотека включва вие самите да посочите във вашия code кой метод да извикате на кой обект, но че използването на рамка обикновено означава, че рамката ще извика вашия code в точното време. С други думи, в този последен случай вие вече не управлявате процеса на изпълнение на codeа/програмата — рамката прави това instead of вас. Предадохте контрола на рамката (инversion на контрола). DI означава инжектиране на зависимости. С инжектирането на зависимости вие не създавате обекти cat в основния метод и след това не ги предавате на вашите методи. Вместо това Spring Framework ги създава за вас. Просто казвате нещо като „Искам да си взема котка тук“ и рамката ви предава такава във вашия метод. Ще видим това съкращение в бъдещи статии.

Фасул и контекст

Една от ключовите концепции на пролетта е боб. Всъщност това е просто обект от няHowъв клас. Да предположим, че имаме програма, която изисква 3 обекта: котка, куче и папагал. И имаме куп класове с куп методи. Понякога се нуждаем от котка за метод, понякога имаме нужда от куче за различен метод, а понякога нашите методи се нуждаят и от котка, и от папагал (например методът за хранене на котката, ха-ха). За други методи са необходими и трите обекта. Да, бихме могли първо да създадем тези три обекта в основния метод и след това да ги предадем на нашите класове, а след това в тези класове да ги предадем на съответните методи... И така нататък в цялата програма. Но ако също така предположим, че понякога искаме да променим списъка с входни параметри за нашите методи (например, решим да пренапишем нещо or да добавим нова функционалност), тогава ще трябва да направим доста промени в codeа. А сега си представете, че имаме не 3, а 300 такива обекта. Една алтернатива би била да съберем всички наши обекти в един списък (List<Object>), предайте го на всеки метод и след това вземете необходимия обект, докато сте вътре в методите. Но докато програмата работи, Howво ще стане, ако няHowъв обект бъде добавен към този списък or по-лошо, Howво ще стане, ако някой бъде изтрит? Това има потенциала да прекъсне всеки метод, при който използваме индекс, за да получим обекти от списъка. За да избегнем този проблем, решаваме да съхраняваме нашите обекти не в списък, а в карта, където ключът е името на обекта, а стойността е самият обект. Това ни позволява да извлечем обектите, от които се нуждаем, просто като използваме името им, например get("parrot"), и в отговор получаваме обекта parrot. Или ключът може да бъде класът на обекта, а стойността може да бъде самият обект. В този случай, instead of да посочите името на обекта, може просто да посочите класа на обекта, от който се нуждаем. Това също е удобно. Или дори можем да напишем няHowъв вид обвивка за картата, където някои методи получават обекти по име, а други методи получават обекти по клас. Това, до което стигнахме тук, се нарича anконтекст на приложението в Spring Framework. Контекстът е колекция от зърна (обекти). Имаме достъп до контекст, за да получим bean-а (обекта), от който се нуждаем, по неговото име, по неговия тип or по няHowъв друг начин. Освен това можем да помолим самата Spring да потърси в собствения си контекст необходимия ни зърн и да го прехвърли на нашия метод. Да предположим например, че имаме метод като този:

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

Когато Spring извика този метод, тя взе нашия обект котка от неговия контекст и го предаде на метода. Но сега решихме, че освен котка, нашият метод се нуждае и от папагал. С пролетта нищо не може да бъде по-лесно! Просто пишем:

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

Сега, когато Spring извиква нашия метод, той разбира необходимостта от предаване на котка и папагал, така че отива в неговия контекст, получава тези два обекта и ги предава на нашия метод. Прехвърляйки юздите на контрола на Spring, ние също прехвърляме отговорността за създаването на обекти и предаването им на нашите методи, които Spring ще извика. Това повдига въпроса: How Spring знае кои обекти (зърна) да създаде?

Начини за конфигуриране на приложение

Има три основни начина за конфигуриране на приложение , тоест начини да кажем на Spring кои точно обекти са ни необходими:

1. XML конфигурационни файлове
2. Базирана на Java конфигурация
3. автоматична конфигурация

Създателите на Spring ги подреждат по приоритет в този ред:

• методът с най-висок приоритет, който трябва да бъде предпочитан, е автоматичната конфигурация
• ако автоматичната конфигурация не може да се използва за правилно конфигуриране на всички възможни компоненти, използвайте Java-базирана конфигурация (която включва създаване на обекти с помощта на Java code)
• и методът с най-нисък приоритет е старомодният начин - използване на XML конфигурационни файлове.

Пролетта също ни позволява да комбинираме тези методи. Например, оставете Spring да конфигурира всичко, което може да бъде конфигурирано автоматично, използвайте базирана на Java конфигурация, където имате нужда от специални параметри, и използвайте XML за всяHowви наследени конфигурации. Всичко това се оказва доста гъвкаво. Все пак, ако всичко може да се конфигурира автоматично, изберете тази опция. Ще разгледам само автоматичната конфигурация и конфигурацията, базирана на Java. XML конфигурациите се използват в почти всеки пример на Spring в Интернет. Нещо повече, след като разберете How работи базираната на Java конфигурация, не би трябвало да имате проблем с четенето на XML файл, който прави същото. Автоматичната конфигурация се използва, когато трябва да работим с обекти от класове, които сме написали. Ако създаването на един от нашите обекти изисква няHowва много специфична логика, or ако не сме в състояние да направим няHowъв клас с анотацията, необходима за автоматична конфигурация, тогава можем да използваме конфигурация, базирана на Java, за да направим това, което трябва да се направи. Вследващата част ще създадем проект на Maven, ще свържем няколко от основните модули на Spring и ще създадем нашите първи зърна.