Czy da się używać Hibenate w celu korzystania z Bazy danych, wraz ze Springiem? Słyszałem, że w Springu lepiej używać spring data zamiast Hibernate.
Jeśli, tak to po co został stworzony Hibernate?
Czy dalej się używa Spring MVC czy tylko "surowego" Springa?
Da się.
Ale po co używać Hibernate jeśli łatwiej użyć Spring Data? W czym jest on lepszy od Spring Data?
Co z drugim pytaniem?
Spring data to projekt skladajacy sie z kilku modulow. Jednym z tych modulow jest np. spring-data-jpa. JPA to dokument opisujacy system ORM. Hibernate jest niczym innym jak implementacja (jedna z wielu) tego standardu. Spring-data-jpa jest bardziej nakladka na JPA (czyli np. na Hibernate) niz jego zamiennikiem. Innymi slowy: zazwyczaj stosuje sie spring-data-jpa wlasnie w polaczeniu z biblioteka typu Hibernate.
Jezeli przyjdzie Ci pracowac z systemem ORM typu JPA (np. z Hibernate) to spotkasz sie glownie z nastepujacymi zagadnieniami:
- Tworzeniem / rozbudowa klas zwanych encjami. Obiekty tych klas moga byc utrwalane w bazie danych. W uproszczeniu mozesz sobie wyobrazic obiekt encji jako pojedynczy rekord w tabeli bazy danych. Encje w duzym stopniu odzwierciedlaja strukture bazy danych (tabele, zwiazki miedzy tabelami itd.). W tym punkcie zalozylem, ze pracujemy na typowej relacyjnej bazie danych.
- Wyciaganiem danych z bazy danych.
- Dodawaniem, usuwaniem i modyfikacja danych przechowywanych w bazie danych.
Trudno jest sie obejsc bez JPA (czyli bez Hibernate lub innej implementacji JPA) podczas prac nad encjami. Natomiast podczas prac nad punktami 2 i 3 warto wykorzystac te cala nakladke, ktora dostarcza spring-data (glownie chodzi o repozytoria, ktore pracuja na encjach) i wlasciwie mozna olac oficjalny sposob dostepu do danych na korzysc ww. nakladki.
Byc moze da sie wykorzystac spring-data w taki sposob aby nie korzystac z JPA, ale polaczenie obu tych rzeczy wydaje mi sie dosc popularne (szczegolnie w sytuacji kiedy Hibernate pelni role implementacji JPA).
Z tego co wiem nadal sie uzywa Spring MVC (moge nie byc na biezaco). Oczywiscie o ile uzycie wzorca MVC jest do czegos potrzebne (nie zawsze jest).
Dzięki za bardzo rozpisana odpowiedź, ale mam jeszcze jedno pytanie. A bardziej doprecyzowanie czegoś innego. Chodziło mi bardziej, czy używa się Spring Boota To co można https://start.spring.io tutaj stworzyć, czy w jakiś inny sposób się używa springa jako FW po stronie serwera?
Spring Boot jest popularny bo przyspiesza pewne rzeczy, ale to nie jest żaden "inny" spring. To jest po prostu zbiór "standardowych" konfiguracji dla pewnych zastosowań.
Co do poprzednich pytań: to się wszystko buduje niejako "na sobie". JPA stoi na JDBC, Spring Data stoi na JPA. Użycie Spring Data nie oznacza że nagle nie masz już w projekcie JPA/Hibernate. To jest tylko taki dodatek który ułatwia pisanie DAO/Repozytoriów.
dalej się używa tego czego się chce używać.
Dzięki Wszystkim za odpowiedź. Trochę mi się już to rozjasnilo.
Jeszcze jedno pytanie mi się nasunelo. Kiedy stosować, albo Kiedy korzystać z, repozytoriow, kiedy z DAO a kiedy z prostych transakcji (pobranych z MenagerFactory)?
Repository to w praktyce to samo co DAO. Z EnttiyManagera korzysta się na poziomie Repository, transakcje są na poziomie logiki biznesowej (czyli serwisów), sa rzadząne deklaratywnie (@Transactional), więc jedyne co trzeba zrobić to ew. konfiguracja JPA
scibi92 napisał(a):
Repository to w praktyce to samo co DAO.
To chyba w Springu, bo w profesjonalnym świecie:
- repozytorium jest jednym z kilku podstawowych tworów DDD, jeśli nie mamy DDD, to nie mamy czego nazwać "repozytorium";
- repozytorium zapewnia wyglądający jak kolekcja dostęp do aggregate rootów (nie encji, bo na pojedynczych encjach nie ma sensu pracować);
- nie musi być związane z bazą danych.
No i generalnie jest to najbardziej niepotrzebny wzorzec projektowy.
No to w Springu mamy Repository zgodnie z założeniami wzorca Repository
Więc czemu piszesz, że to to samo co DAO?
Repository to może być DAO jeśli nie masz DDD (masz encje anemiczne) i wystarczy Ci jedna tabela - bo DAO zwykle dotyczy jednej tabeli. W szczególności opis Fowlera dla Repository wygląda jak przepis na DAO. Zresztą w Spring DAO można zrobić przez adnotację @Repository.
DAO i Repository to generalnie Data Access Layer. W obu przypadkach to abstrakcja która nie musi byc zwiazana tylko z bazą danych
vpiotr napisał(a):
Repository to może być DAO jeśli nie masz DDD
Jeśli nie mam DDD, to nie mam też repozytorium. Mogę sobie mieć jakieś DAO, które programiści uczący się programowania enterprise z hinduskich tutoriali nazywają repozytorium, ale błędna nomenklatura nie zmienia rzeczywistości.
W szczególności opis Fowlera dla Repository wygląda jak przepis na DAO.
No, zwłaszcza:
A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object collection.
oraz:
Conceptually, a Repository encapsulates the set of objects persisted in a data store and the operations performed over them, providing a more object-oriented view of the persistence layer.
Zresztą w Spring DAO można zrobić przez adnotację @Repository.
Tak, twórcy jakiejś biblioteki nie rozumieją wzorca, więc nazywają sobie tak losowe klasy. Jestem prawie przekonany, że to słuszne.
scibi92 napisał(a):
DAO i Repository to generalnie Data Access Layer. W obu przypadkach to abstrakcja która nie musi byc zwiazana tylko z bazą danych
Nie, repozytorium jest ponad warstwą dostępu do danych.
Dobra, idę stąd, bo to w końcu nie jest dział na poważne programowanie tylko Java.