Spring Framework vs SpringBoot - miwanek/Omami GitHub Wiki

Czym jest Spring Framework?

Jest to szkielet (framework) do tworzenia wydajnych aplikacji typu "enterprise" w języku Java. Powstał jako alternatywa dla programowania aplikacji z użyciem EJB(Enterprise JavaBeans, czyli jeden z komponentów Javy Enterprise Edition). Programowanie z użyciem EJB narzucało wiele ograniczeń – wymagając między innymi przyjęcia określonego modelu tworzenia oprogramowania, a stworzenie nawet prostej aplikacji wymagało dużo pracy. Spring Framework powstał za to jako lekki szablonu, który nie wymusza na programiście konkretnych rozwiązań, pozostawiając za to wiele opcji do wyboru. W efekcie, w obecnej chwili Spring Framework stał się wiodącą technologią na rynku.

Głównym elementem Spring Framework jest kontener wstrzykiwania zależności(IoC contener). Wstrzykiwanie zależności(dependency injection) jest jedną z implementacji koncepcji odwróconego sterowania(inversion of control).

Poza najważniejszym i najbardziej znanym elementem, framework ułatwia między innymi:

  • operacje na bazach danych za pomocą JDBC i ORM(object relational mapping)
  • testowanie kodu
  • programowanie aspektowe
  • tworzenie aplikacji webowych
  • integracje z JMS i innymi elementami Javy EE

Czym NIE jest Spring Framework?

Wiele osób w początkowej styczności z szeroko pojętym ekosystemem Springowym gubi się w natłoku pojęć. Często zaczynamy naszą przygodę z nim od wygenerowania projektu w Spring Initializr. Parę kliknięć i bach mamy działający serwer, na który możemy wysyłać już zapytania HTTP. Jest to jednak zasługa innego projektu z rodziny Spring, znanego jako Spring Boot. O ile Spring Framework udostępnia nam potężne narzędzia i możliwości konfigurowania aplikacji, to nie robi jednak niczego za nas. W tym momencie wkracza jednak Spring Boot, który przygotowuje dla nas bazowe konfiguracje dla niezbędnych dla naszej aplikacji elementów.

Ekosystem Springa jest bardzo złożony i składa się z wielu niemal niezależnych projektów. Na grafice poniżej każdy symbol reprezentuje inny projekt Springa, a te przecież mogą składać się z wielu podprojektów !

Spring Boot - zalety i wady

Wraz ze wzrostem popularności Spring Framework szybko zauważono, że konfiguracje wielu niezbędnych dla typowych aplikacji komponentów są bardzo powtarzalne. Z tego spostrzeżenia zrodził się Spring Boot - projekt, który ułatwia obecnie życie tysiącom programistów na całym świecie. Bazuje on na idei "convention over configuration", która zakłada konfigurowanie tylko niestandardowych zachowań aplikacji. Spring Boot na starcie zapewnia nam wbudowany kontener aplikacyjny, gotowe autokonfiguracje(np. Entity Managera przydatnego do operacji na bazie danych)

Plusy:

  • szybszy development,
  • uproszczone konfiguracje,
  • większa produktywność,
  • programista może w pełni skupić się na logice biznesowej

Minusy(a właściwie jeden):

  • z racji na ilość rzeczy, które dzieją się poza świadomością przeciętnego programisty odnalezienie co tak właściwie nie działa w naszej aplikacji może zająć bardzo dużo czasu i wysiłku. Typowa reakcja na problemy ze Spring Bootem

Magia Spring Boota, czyli jak to właściwie działa

Spring Boot wykonuje kawał pracy za nas poprzez swoje autokonfiguracje. Są to specjalne konfiguracje przygotowane przez twórców Springa lub twórców zewnętrznych bibliotek, które w oparciu o zależności w naszym projekcie tworzą niezbędne dla nas beany. Jeżeli w naszym projekcie mamy dependecy do jakiegoś ORM(np. Hibernate) to Spring Boot z marszu wrzuci do kontekstu aplikacji beana Entity Managera. Autokonfiguracje są odpalane zawsze PO naszych własnych konfiguracjach. Jeżeli zdefinijuemy już gdzieś naszego własnego beana Entity Managera, to ten domyślny ze Springa zostanie pominięty.

Istnieje szereg adnotacji pozwalających określić kiedy jakaś autokonfiguracja powinna zostać włączona:

  • @ConditionalOnClass autokonfiguracja zostanie odpalona tylko, gdy jakaś klasa jest na classpath(czyli zazwyczaj gdzieś w zależnościach projektu)
  • @ConditionalOnBean autokonfiguracja zostanie odpalona tylko jeśli w kontekście Springowym mamy już danego beana
  • @ConditionalOnProperty oczekujemy, że dane property(np. spring.datasource.driverClassName) będzie miało określoną wartość
  • @ConditionalOnWebApplication zezwalamy na autokonfigurację tylko jeśli jest to aplikacja webowa

Aby autokonfiguracja została odpalona muszą zostać spełnione wszystkie jej warunki.

Istnieją oczywiście warunki przeciwne do powyższych: @ConditionalOnMissingClass, @CoditionalOnMissingBean, @ConditionalOnNotWebApplication

Oraz wiele innych warunków, nieco mniej używanych. Spring Boot jest na tyle elastyczny, że możemy tworzyć w nim własne warunki czy nawet własne autokonfiguracje ! Jest to jednak temat nieco bardziej złożony.

Jak włączyć w naszej aplikacji autokonfiguracje?

To jednak trzeba je jakoś włączać? :)

W praktycznie każdym projekcie w Spring Boot możemy spotkać klasę podobną do takiej:

@SpringBootApplication
public class OmamiApplication {

	public static void main(String[] args) {
		SpringApplication.run(OmamiApplication.class, args);
	}
}

Nie każdy jednak zdaje sobie sprawę, że adnotacja @SpringBootApplication włącza szereg kluczowych funkcjonalności, bez których nie wyobrażamy sobie aplikacji w Spring Boot.

Przede wszystkim, zawiera ona w sobie dwie kluczowe adnotacje:

  • @EnableAutoConfiguration, która zezwala na wszystkie autokonfiguracje(to czy konkretne zostaną włączone zależy już od warunków odpalenia danej autokonfiguracji).
  • @ComponentScan - wszystkie pakiety znajdujące się na tym samym poziomie lub niższym od klasy zawierającej @SpringBootApplication zostaną przeskanowane w poszukiwaniu klas oznaczonych przez @Component, @Service, @Controller, @Configuration. Na podstawie tych klas zostanie zapełniony kontener Springowy.

Jeżeli w naszym projekcie są jakieś klasy, których reprezentantów brakuje w kontenerze, to warto sprawdzić, czy nie są przypadkiem zbyt wysoko w hierarchi pakietów i przez to są pomijane podczas skanowania.