Hibernate a Spring.

0

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?

0

Da się.

0

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?

2

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:

  1. 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.
  2. Wyciaganiem danych z bazy danych.
  3. 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).

0

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?

1

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.

0

dalej się używa tego czego się chce używać.

0

Dzięki Wszystkim za odpowiedź. Trochę mi się już to rozjasnilo.

0

Jeszcze jedno pytanie mi się nasunelo. Kiedy stosować, albo Kiedy korzystać z, repozytoriow, kiedy z DAO a kiedy z prostych transakcji (pobranych z MenagerFactory)?

0

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

0
scibi92 napisał(a):

Repository to w praktyce to samo co DAO.

To chyba w Springu, bo w profesjonalnym świecie:

  1. repozytorium jest jednym z kilku podstawowych tworów DDD, jeśli nie mamy DDD, to nie mamy czego nazwać "repozytorium";
  2. repozytorium zapewnia wyglądający jak kolekcja dostęp do aggregate rootów (nie encji, bo na pojedynczych encjach nie ma sensu pracować);
  3. nie musi być związane z bazą danych.

No i generalnie jest to najbardziej niepotrzebny wzorzec projektowy.

0

No to w Springu mamy Repository zgodnie z założeniami wzorca Repository

0

Więc czemu piszesz, że to to samo co DAO?

0

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.

0

DAO i Repository to generalnie Data Access Layer. W obu przypadkach to abstrakcja która nie musi byc zwiazana tylko z bazą danych

0
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.

1 użytkowników online, w tym zalogowanych: 0, gości: 1