Kontekst serwletu i obiekty nasłuchujące w aplikacjach webowych
21 kwietnia 2017
deskryptor wdrożenia artykuł
Deskryptor wdrożenia w aplikacjach webowych
27 kwietnia 2017
pogodynka artykuł

Raport z frontu Pogodynki część 6. Dzisiaj pokrótce opisuję konfigurację warstwy dostępu do bazy danych. Sama konfiguracja skończyła się na dodaniu kilku zależności i magicznych adnotacji, które postaram się wyjaśnić.

Baza danych

Dla celów testowych i na “środowisku developerskim” (czytaj moim własnym komputerze) używam prostej bazy danych. Mam tu na myśli HyperSQL. Jest to baza danych, której zawartość może być trzymana wyłącznie w pamięci.

Tego typu rozwiązanie idealnie nadaje się do pracy na środowisku programistycznym. Często też bazy danych tego typu używane są w trakcie testów integracyjnych. W trakcie takich testów możliwe jest testowanie właściwej integracji z bazą danych.

Dostęp do tej bazy danych możliwy jest po dodaniu jednej linijki do konfiguracji Gradle

compile group: 'org.hsqldb', name: 'hsqldb', version: '2.4.0'

Jeśli chcesz dowiedzieć się czegoś więcej o samym Gradle zachęcam do przeczytania wprowadzenia do Gradle.

JPA i ORM

I tu wchodzą nam dwie wielkie kobyły ;). JPA czyli Java Persistence API i ORM czyli Object-Relational Mapping. JPA to specyfikacja, która została włączona do specyfikacji EJB (ang. Enterprise Java Beans). Specyfikacja ta określa mechanizmy, które pozwalają na „proste” zarządzanie zawartością bazy danych przez obiekty w Java.

Innymi słowy instancje klas odpowiadają wierszom w bazie danych. Mapowanie zawartości bazy danych na obiekty Javy to “mapowanie obiektowo-relacyjne” – ORM. Najszerzej stosowaną implementacją JPA jest Hibernate. To właśnie tę implementację użyłem w Pogodynce. Aby uzyskać wsparcie Hibernate niezbędne są następujące zależności:

ORM

Nie wchodząc w szczegóły samego JPA i Hibernate opiszę co udało mi się osiągnąć. Przy pomocy odpowiednich adnotacji w kodzie Javy mapuję obiekty klasy TemperatureMeasurement na wiersze w tabeli temperature_measurements. Całość wymagała kilku adnotacji w kodzie oraz dodatkowej konfiguracji, która pozwoliła na mapowanie typu DateTime na odpowiedni typ w bazie danych.

Jedyny obiekt modelu, który aktualnie jest dostępny wygląda następująco:

Warstwa dostępu do danych

Warstwa DAO (ang. Data Access Object) jest automatycznie generowana. Są to obiekty pośredniczące zarządzane przez Spring. Interfejs DAO, którym posługuję się w aplikacji sprowadza się do kilku linijek:

Taka “magia” dostępna jest dzięki użyciu Spring Data:

Magiczna konfiguracja Spring

Całość konfiguracji to jeden nowy plik. Tworzy on odpowiednie obiekty, które wymagane są przez specyfikację JPA

Podsumowanie

Na dzień dzisiejszy mam “gotową” aplikację webową, która wystawia dwa adresy URL. Pozwalają one na utworzenie nowej instancji pomiaru temperatury i pobrania wszystkich istniejących pomiarów. Kolejnym krokiem będzie zaimplementowanie “logowania” użytkowników i wystawienia takiej aplikacji na świat. Następnie będę mógł zintegrować czujnik z tak działającą aplikacją.

Po kilku dniach działania aplikacji będę miał wystarczająco dużo rzeczywistych pomiarów temperatury, które pozwolą mi na pracę nad interfejsem użytkownika.

Jeśli chcesz zobaczyć aktualną wersję aplikacji możesz ją znaleźć na samouczkowym githubie. Trzymaj się i do następnego razu!

[FM_form id=”3″]

Zdjęcie dzięki uprzejmości https://www.flickr.com/photos/rubysfeast/7149704201/sizes/l