Home > JPA, ORM > Pierwsza noc z Hibernate

Pierwsza noc z Hibernate

Hibernate zafascynował mnie od chwili, gdy pierwszy raz ujrzałem dokumentacje. Zamieszczone przykłady obiecywały mi rozwiązanie najgorszych problemów programowania w PHP. Wczoraj spędziłem noc z Hibernate i muszę przyznać, że jestem zachwycony. Hibernate jest lepszy, niż to sobie wyobrażałem. Dokonałem cudu. Udało mi się osiągnąć to, co chciałem.

Hibernate to biblioteka programistyczna umożliwiająca mapowania obiektowo relacyjne.

Każdy programista PHP zdaje sobie sprawę z konieczności pisania SQL, które będą pobierać dane z bazy, modyfikować rekordy lub robić inne dziwne operacje na relacjach. W PHP zwykle osadza się kod SQL gdzieś tam w skrypcie. Niekiedy, piszę się procedury, które budują bardziej skomplikowany kod SQL, po to tylko, żeby za moment wykonać go w bazie danych. Ten rodzaj pracy przyczynia się do powstawania błędów. Rozwiązaniem problemu, jest przeniesienie skryptów SQL do osobnego miejsca – wyodrębnie SQL od kodu PHP.

Hibernate rozwiązuje ten problem jeszcze lepiej. Nie trzeba pisać zapytań SQL. Wystarczy stworzyć obiekty, klasy Java, a następnie opisać w jakis sposób te obiekty mają być mapowane na pola w relacyjnej bazie danych. To hibernate dba o to, by w bazie danych znalazły się aktualne rekordy. Hibernate aktualizuje także strukturę bazy danych. Ze smutkiem przyznaje, że gigantyczna porcja mojej wiedzy dotyczącej programowania bazy PostgreSQL w obliczy technologi ORM jest mi właściwie zbędna. Ale jako początkujący programista ORM jestem w stanie napisać lepszy program, niż jako zaawansowany programista PostgreSQL.

Categories: JPA, ORM Tags:
  1. crs
    June 2nd, 2006 at 13:35 | #1

    Hibernate? To z Javy? Mozna tego uzywac z innymi jezykami?

  2. Antoni Jakubiak
    June 2nd, 2006 at 16:13 | #2

    Hibernate to z Java. Prawdopodobnie można też używać z dotnetem. Dla innych języków również istnieja mniej lub bardziej udane narzędzia do mapowania obiektowo relacyjnego.

  3. Anonymous
    June 8th, 2006 at 06:30 | #3

    Nie przekreślaj od razu PostgreSQL…

    Mapowanie obiektowo relacyjne wcale
    nie jest taką fajną sprawą – użyteczne
    jest to przy pobieraniu danych do
    obiektu. Zmiany i tworzenie obiektów
    generować mogą niepotrzebne problemy
    z transakcjami, powodują też nierzadko
    niepotrzebny narzut obliczeniowy.

    W takich przypadkach powinieneś jednak
    pozostać przy funkcjach PostgreSQL. Jest to bezpieczniejsze i pozwala na łatwiejszą integrację z innym oprogramowaniem.

    Pozdrawiam,
    MArcin Gajda (aka zboczuch)

  4. Antoni Jakubiak
    June 8th, 2006 at 09:17 | #4

    Nie zgodzę się z Tobą.

    Nie przekreślam PostgreSQL. Dalej będę używał tej bazy.

    W aplikacjach które dotychczas pisałem update dużej liczby rekordów jest rzadko spotykany. Wydaje mi się, że EJB3 jest w stanei zoptymalizowąć tego typu czynności.

    Zawsze byłem przeciwnikiem pisania funkcji do bazy danych. Pisanie takich funkcji powoduje przeniesienie ciężaru logiki biznesowe z programu do bazy, oraz uzalężnia aplikację od konkretnej bazy danych.

    Patrząc z punktu widzenia MVC przenoszenie logiki biznesowej do bazy danych jest dziwnym zabiegiem.

    Patrząc z punktu widzenia biznesu, aplikacja zależna od komponentów traci.

    Piszesz o problemach z transakcjami. Warto sięgnąć po specyfikację EJB. Przy pomocy meta języku definiujesz jak wykonywać transakcję. Możesz określić czy funkcja ma rozpocząć nową transakcję lub na przykład czy musi pracować w obrębie już istniejącej transakcji.
    Wyobraź sobie próbę napisania czegoś takiego w PHP :))

    Narzut obliczeniowy jest do przejścia. Dzięki EJB lub Hibernate możesz stosować architekturę prostą do rozbudowy. Potrzebujesz więcej mocy obliczeniowej – kupujesz nowy serwer i łączysz go na poziomie serwera aplikacji. Twój kod programu pozostaje bez zmiany.

    Zawsze lepiej jest marnować moc obliczeniową, niż godziny pracy programistów.

    Uzależnianie się od funkcji PostgreSQL oznacza zawężenie liczby odbiorców aplikacji. Klient może zrezygnować z zakupu takiej aplikacji, bo np.: posiada dobrych, przeszkolonych i certyfikowany administratorów MySQL. (MySQL zrobił ostatnio duży krok do przodu)

    Pisanie funkcjie Postgresa na pewno być może ułatwi integracja naszego softu z naszym softem. Na pewno jednak utrudni integracji naszego softu z już istniejącym softem.

    Chętnie podyskutuje

    Antek

  5. Tomasz Rup
    June 25th, 2006 at 20:21 | #5

    Zobacz projekt Propel. Wygląda ciekawie. Spróbuję go porównac z Hibernate.

  6. Anonymous
    October 12th, 2006 at 10:37 | #6

    Witam!
    Z własnego dioświadczenia. HIbernate dobrze sprawdza się wszędzie gdzie masz duże obiekty w sensie mające dużo pól. Wtedy zamiast pisać potworki SQLowe piszę prostrze zapytania HQL.
    Co do PostgreSQL. Niewatpliwie zaleta jest szybkość działania gdy pominiemy jakąś pośrednią warstę. Jednak fajnie jest jak aplikacjia będzie całkowicie niezależna nie tylko od konkretnej bazy ale też od jej typu. Klient może w kazdej chwilo opwiedzieć iż przechodzi w dniu jutrzejszym na np. DB2 lub MySQL. Nas to nie będzie bolało bo kod JAvy nie będzie nawet ruszony. Zmieni się tylko wpisy w configach i zrestartuje serwer. Całośc zajmie max 5 minut :) Zmiana kodu może być duuuuużo bardziej czasochłonna a tym samym znacznie droższa :)

  7. Anonymous
    October 12th, 2006 at 10:38 | #7

    Witam!
    Z własnego dioświadczenia. HIbernate dobrze sprawdza się wszędzie gdzie masz duże obiekty w sensie mające dużo pól. Wtedy zamiast pisać potworki SQLowe piszę prostrze zapytania HQL.
    Co do PostgreSQL. Niewatpliwie zaleta jest szybkość działania gdy pominiemy jakąś pośrednią warstę. Jednak fajnie jest jak aplikacjia będzie całkowicie niezależna nie tylko od konkretnej bazy ale też od jej typu. Klient może w kazdej chwilo opwiedzieć iż przechodzi w dniu jutrzejszym na np. DB2 lub MySQL. Nas to nie będzie bolało bo kod JAvy nie będzie nawet ruszony. Zmieni się tylko wpisy w configach i zrestartuje serwer. Całośc zajmie max 5 minut :) Zmiana kodu może być duuuuużo bardziej czasochłonna a tym samym znacznie droższa :)

  8. Anonymous
    October 12th, 2006 at 10:39 | #8

    Witam!
    Z własnego dioświadczenia. HIbernate dobrze sprawdza się wszędzie gdzie masz duże obiekty w sensie mające dużo pól. Wtedy zamiast pisać potworki SQLowe piszę prostrze zapytania HQL.
    Co do PostgreSQL. Niewatpliwie zaleta jest szybkość działania gdy pominiemy jakąś pośrednią warstę. Jednak fajnie jest jak aplikacjia będzie całkowicie niezależna nie tylko od konkretnej bazy ale też od jej typu. Klient może w kazdej chwilo opwiedzieć iż przechodzi w dniu jutrzejszym na np. DB2 lub MySQL. Nas to nie będzie bolało bo kod JAvy nie będzie nawet ruszony. Zmieni się tylko wpisy w configach i zrestartuje serwer. Całośc zajmie max 5 minut :) Zmiana kodu może być duuuuużo bardziej czasochłonna a tym samym znacznie droższa :)

  9. pawel
    August 12th, 2011 at 14:06 | #9

    Gdzie znajdę hibernate pod php ?
    Na stronie projektu hibernate nic nie ma o php.

  1. No trackbacks yet.

Subscribe without commenting