Od czasów starożytnych, ponieważ Java nie była nazywana Dębem, ale Jawą, niosła ze sobą jedno niezatarte przesłanie: „uruchamiaj każde żelazo”. Ta wiadomość została rozpowszechniona kilka razy w różnych obszarach. Oferuję krótkie wprowadzenie, które ma zastosowanie w aplikacjach bazodanowych Java.
W trakcie samego rozwoju języka Java, w połowie lat 90., jego twórcy wpadli na rewolucyjny pomysł: „ujednolicmy polecenia obsługujące bazę danych, stwórzmy interfejsy, które każdy producent bazy danych zaimplementuje na swój sposób”. JDBC (Java Database Connectivity) odbudowuje ujednolicony interfejs API do pracy z bazami danych. Ten ujednolicony interfejs pozwolił programistom skoncentrować się na programowaniu, bez konieczności zajmowania się kompatybilnością poleceń w różnych typach baz danych.
Pamiętasz, jak programy uzyskiwały dostęp do zasobów baz danych pod koniec lat 90-tych? Chyba się starzeję, ale pamiętam to. Np. popularny Delphi - inny typ bazy danych, inne źródło, inne polecenia.
To tradycyjne jawajskie podejście do baz danych wymagało połączenia ze źródłem bazy danych i wydania klasycznego polecenia SQL. Jeśli programista chciał, aby aplikacja była naprawdę „szalona”, musiał poradzić sobie z różnymi krytycznymi przypadkami, takimi jak niedostępność zasobów bazy danych lub awaria połączenia z bazą danych. Być może najgorszym możliwym przypadkiem, jaki może się zdarzyć, jest to, że programista zjawiska skompilował polecenie do bazy danych, którego użył do wyodrębnienia danych i nie zamknął zestawu wyników. Mogłoby to spowodować wyrzucenie na serwer aplikacji innych programów, które w ogóle nie musiały być programowane w tym zjawisku.
Dużą wadą tego podejścia jest to, że zakładane polecenia SQL są różne dla różnych typów baz danych. Tak, można by zastosować standardowe zapytania zgodne ze specyfikacją ANSI, ale wtedy nie skorzystalibyśmy ze specyficznej implementacji silnika bazy danych.
Kolejną wadą jest to, że proces odwzorowujący logikę aplikacji na polecenia SQL nie jest precyzyjnie zdefiniowany. Mapowanie to zwykle powstaje intuicyjnie w głowie programisty, bez koncepcji, co jest zarówno źródłem błędów, jak i co więcej, taka koncepcja uniemożliwia łatwą rozbudowę aplikacji samodzielnej/webowej. Te intuicyjne mapowania obiektów do baz danych są zwykle ściśle powiązane, co może powodować poważne problemy podczas zarządzania aplikacją.
Mapowanie obiektowo-relacyjne (ORM) dokładnie określa, w jaki sposób będziemy mapować jednostki z bazy danych na obiekty. W duchu ORM powinniśmy stworzyć proste klasy POJO (Plain Old Java Object). Instancje tych klas POJO utworzą pojedyncze wiersze tabel (np. również połączone).
Interfejs Java Persistence API (JPA) reprezentuje specyfikację tego przetworzonego mapowania obiektowo-relacyjnego. JPA można rozumieć jako całkowity standard niezależności od RDBMS (Relational Database Management System). MySQL, MariaDB, Oracle, PostgreeDB itp. Zgadza się, poza samą specyfikacją JPA, reprezentuje ona uniwersalność programów pisanych z wersji bazodanowej.
JPA to poważna sprawa. Posuwa się tak daleko, że ma własny język do pisania klas baz danych, JPQL (Java Persistence Query Language). Idealnie byłoby, gdybyś w ogóle nie potrzebował JPQL. Możesz zadowolić się klasami POJO, które wstawiasz (lub wybierasz z) menedżera encji. Menedżer encji zajmuje się wszystkim automatycznie - umieszcza polecenie SQL w określonym dialekcie RDBMS.
Środowisko obiektowo-relacyjne Hibernate umożliwiające wysokowydajne mapowanie obiektowo-relacyjne w aplikacjach napisanych w języku Java. Można powiedzieć, że Hibernate jest rozszerzeniem JPA (Java Persistence API) opracowanym przez firmę RedHat.
Framework ten jest objęty licencją LGPL, dzięki czemu można go bezpłatnie pobrać i zintegrować z aplikacjami Java. Zasadniczo wystarczy skopiować kilka linii do pliku konfiguracyjnego maven i gotowe.
Zasada Hibernacji jest następująca: tworzysz obiekty POJO, które kopiują ustawienia (bieżące lub przyszłe!) bazy danych. Następnie dodajesz adnotacje do tych obiektów zgodnie ze specyfikacją, aby Hibernate zgadł, co to jest tabela, a co atrybut. Następnie tworzysz program hibernujący, w którym wstawiasz lub z którego wybierasz takie obiekty. Hibernate zajmuje się samymi instrukcjami SQL! Co więcej, jeśli nie masz utworzonej bazy danych, możesz zlecić Hiberantowi utworzenie jej zgodnie z określonym mapowaniem! Istnieje również proces odwrotny, w którym tworzysz obiekty mapujące POJO z istniejącego schematu bazy danych zgodnie z adnotacjami hibernacji.
Z Hibernacji można korzystać w aplikacjach Java Enterprise, a także w zwykłych, samodzielnych aplikacjach.