[Java] JPA VS. Hibernate

[Verwijderd]

Hey,

We werken nu aan een project en we doen het voor de eerste keer in Java. Nu staan we voor de moeilijke keuze tussen JPA en Hibernate.
Het probleem is, in mijn ogen, dat je via JPA teveel de persistentie laag koppelt met de domein laag, zo geef je de beans, die normaal niets van intiligentie hebben, redelijk wat intiligentie.
Koppel je de database niet te hard aan de beans?
Wat zijn de voordelen van JPA en welke van Hibernate?
Het team moet opgeleid zijn ook, dus hier kan ook rekening mee gehouden zijn.

[Alarmnummer]

JPA is een specificatie en Hibernate levert van deze specificatie een implementatie.

Persoonlijk werk ik nooit met JPA, gebruik nog netjes de Hibernate functionaliteit. En via Spring heeft het hele systeem toch geen weet van de specifieke or technology.

Waarom denk je dat je domain objecten te veel persistance logica krijgen? Omdat je met al die vieze annotations zit? (metadata good.. annotations: a missused technology). Daarom werk ik zelf liever met mapping files. Hierdoor zit je hele mapping aspect mooi in een file.

Repositories (DAO's) zie ik als persistent collections, dus daarom zijn ze onderdeel van het domein.

[rrrandy]

Alarmnummer schreef op dinsdag 12 februari 2008 @ 18:33:
JPA is een specificatie en Hibernate levert van deze specificatie een implementatie.

Persoonlijk werk ik nooit met JPA, gebruik nog netjes de Hibernate functionaliteit. En via Spring heeft het hele systeem toch geen weet van de specifieke or technology.

Waarom denk je dat je domain objecten te veel persistance logica krijgen? Omdat je met al die vieze annotations zit? (metadata good.. annotations: a missused technology). Daarom werk ik zelf liever met mapping files. Hierdoor zit je hele mapping aspect mooi in een file.

Repositories (DAO's) zie ik als persistent collections, dus daarom zijn ze onderdeel van het domein.

Eerste keer dat ik hoor dat iemand mapping files prefereert boven annotations....

Mapping files zijn imho slecht te onderhouden met refactoring mogelijkheden van nul komma nul (of heb je een briljante tool?). Extra code toevoegen vind ik ook rampzalig. Hoe vaak het mij niet wel is overkomen dat ik code aan een bean had toegevoegd en vergeten was deze te kopieren naar mijn mapping file waardoor ik bij het genereren van mijn model weer alles kwijt was...

Niet dat annotations ideaal zijn (op sommige punten verre van dat), maar die mapping files vind ik een typisch geval van sadomasochisme

/edit:
Om ook nog maar even een antwoord te geven op de vraag van de topic starter:

De annotations uit de java persistence api zijn erg algemeen. Bepaalde dingen die je gaat willen als je hibernate gebruikt zoals indexes bijvoorbeeld worden door JPA niet ondersteund. En dat is ook logisch. JPA is onafhankelijk van welke implementatie je er onder schuift en kan ook worden gebruikt voor andere vormen van persistency dan een database. Ben je van plan om je beans alleen naar een database te persisten dan zou ik gewoon voor de hibernate annotations gaan. Wanneer je voor JPA kiest kom je er toch al snel achter dat puur JPA voor een database tekort schiet.

[ Voor 19% gewijzigd door rrrandy op 12-02-2008 21:08 ]

[-FoX-]

rrrandy schreef op dinsdag 12 februari 2008 @ 20:59:
[...]
Eerste keer dat ik hoor dat iemand mapping files prefereert boven annotations....

Tweede keer bij deze

Mapping files zijn imho slecht te onderhouden met refactoring mogelijkheden van nul komma nul (of heb je een briljante tool?). Extra code toevoegen vind ik ook rampzalig. Hoe vaak het mij niet wel is overkomen dat ik code aan een bean had toegevoegd en vergeten was deze te kopieren naar mijn mapping file waardoor ik bij het genereren van mijn model weer alles kwijt was...

Niet dat annotations ideaal zijn (op sommige punten verre van dat), maar die mapping files vind ik een typisch geval van sadomasochisme

Bwa, met een goede IDE (IntelliJ snel snel, want ze gaan opslaan!! ) kan dat allemaal hoor. IntelliJ biedt uitstekende support voor Hibernate (en Spring) out-of-the-box.

/edit:
Om ook nog maar even een antwoord te geven op de vraag van de topic starter:

De annotations uit de java persistence api zijn erg algemeen. Bepaalde dingen die je gaat willen als je hibernate gebruikt zoals indexes bijvoorbeeld worden door JPA niet ondersteund. En dat is ook logisch. JPA is onafhankelijk van welke implementatie je er onder schuift en kan ook worden gebruikt voor andere vormen van persistency dan een database. Ben je van plan om je beans alleen naar een database te persisten dan zou ik gewoon voor de hibernate annotations gaan. Wanneer je voor JPA kiest kom je er toch al snel achter dat puur JPA voor een database tekort schiet.

JPA = een specificatie
Hibernate implementeert deze specificatie.

Als je bijvoorbeeld JBoss gaat gebruiken als application server, en je maakt gebruik van JPA, zal je onderliggend toch gewoon Hibernate aan het gebruiken zijn zonder dat je het weet.

Mijn voorkeur zou uitgaan naar Hibernate, omdat je toch met dezelfde technologie aan het werken bent. Maar daar waar de specificatie een stoffige specificatie blijft.. er is wel over nagedacht, maar het duurt lang eer er een update komt.. evolueert Hibernate wel leuk mee.

[Verwijderd]

Dus, JPA doet meer dan met je database communiceren. De reden waarom wij hier een tool willen gebruiken is om lazy materialization, niets anders. Ik ben nog niet zolang bezig met JAVA, enkele 3 jaar in school verband, dus veel ervaring heb ik nog niet. Het is wel een zeer moeilijke keuze vind ik persoonlijk. Ik snap het standpunt wel dat je telkens je mapping files moet gaan aanpassen, maar dat je annotations dit voor je doen. Ik heb met beide zeer zeer kort gewerkt, dus veel ervaring heb ik niet.
Morgen moet ik het besluit vormen wat we gaan gebruiken, ik ben er nog niet uit

/edit:

de laatste post heeft veel verduidelijkt, maar ik had deze nog niet gezien toen ik poste

[ Voor 8% gewijzigd door Verwijderd op 12-02-2008 21:38 ]

[Alarmnummer]

rrrandy schreef op dinsdag 12 februari 2008 @ 20:59:
[...]
Eerste keer dat ik hoor dat iemand mapping files prefereert boven annotations....

Wen er maar aan De development community heeft er een handje van om door te slaan..

Mapping files zijn imho slecht te onderhouden met refactoring mogelijkheden van nul komma nul (of heb je een briljante tool?).

IntelliJ idea is erg sterk voor dit soort dingen. Maar over het algemeen zit de complexiteit meer in het begrijpen wat een class doet, en dan wil ik niet nog een keer alle annotations in my face hebben.

Extra code toevoegen vind ik ook rampzalig. Hoe vaak het mij niet wel is overkomen dat ik code aan een bean had toegevoegd en vergeten was deze te kopieren naar mijn mapping file waardoor ik bij het genereren van mijn model weer alles kwijt was...

Dan moet je je tooling een keer na laten kijken denk ik.

Niet dat annotations ideaal zijn (op sommige punten verre van dat), maar die mapping files vind ik een typisch geval van sadomasochisme

Met de tijd komt de wijsheid denk ik maar zo

[jAnO!]

En daar is 4! Niet alleen met Hibernate trouwens, ook bij bijv simpele AOP met Spring bijv. logging of perfmonitoring vind ik het netter om de class definitie puur JAVA code (en ja annotations zijn dat ook, maar....) te laten, configuratie kan dan netjes in een XML en met een fatsoenlijke IDE (voor dit voorbeeld voldoet Spring IDE quit nice) kan je toch mooi zien of je method opgepikt wordt. Crosscutting concerns hou je dan netjes seperate, in je class enkel functionaliteit die je verwacht. Nu is er voor annotations vaak ook wat te zeggen, maar zeker niet in de mate die je ze nu vaak ziet en zeker ook niet als je met goede tooling de boel ook inzichtelijk kan maken.

[flowerp]

rrrandy schreef op dinsdag 12 februari 2008 @ 20:59:
[...]
Eerste keer dat ik hoor dat iemand mapping files prefereert boven annotations....

En een -beetje- meld 5 zich hier

Annotations hebben wel degelijk erg handige toepassingen, maar ik weet nog steeds niet of ik gelukkig wordt van 10 regels Java code met daarom heen 100 regels annotations. Bij een goed design ga je juist uit van een scheiding van verantwoordelijkheden. Je entity in een Java file; lekker clean met alleen wat getters/setters en eenvoudige logic, en alle mapping details in een aparte file.

Elke file heeft dan 1 duidelijke verantwoordelijkheid en de mapping staat letterlijk los van je class. Stel je voor dat je deze class ook wilt gebruiken in een context die helemaal niets met de OR mapping te maken heeft, en stel voor dat deze context weer andere annotations gebruikt. Dan heb je 2 sets van annotations in je class door elkaar die onderling niets met elkaar te maken hebben!

In zekere zin zie ik de mapping als een user van je class, en niet als een onderdeel van je class. De class hoeft niet te weten wie hem allemaal op welke mannier gebruikt, en zou dus ook niet de mapping (in de vorm van annotations) hoeven te bevatten.

Aan de andere kant kun je stellen dat de class (de entity) -alleen- bestaat voor de mapping, en dat het ding buiten de OR mapping om geen enkele functie heeft of kan hebben. Via die visie zou je kunnen zeggen dat de mapping data in een aparte file omslachtig is en dat annotations wel handiger zijn.

Nog zo'n ding zijn de names queries. Wij hebben b.v. tijde lang code lopen te refactoren om alle inline JDBC based SQL uit de Java classes te halen en te verhuizen naar hun eigen files. Nu met JPA echter gaat iedereen weer lekker queries in de Java code zetten. Zij het deze keer niet direct in een String, maar als meta data.

[Confusion]

Los van de al genoemde bezwaren: annotations zijn minder overzichtelijk. In een mapping file heb je in 1 keer overzicht over een mapping, omdat de mapping in zijn geheel op je scherm staat. Als ik het vanuit de annotations wil uitvinden, blader ik me suf en ben ik onderaan alweer vergeten welke annotations er bovenaan stonden: je verliest verbanden uit het oog.

flowerp schreef op woensdag 13 februari 2008 @ 00:41:
Nog zo'n ding zijn de names queries. Wij hebben b.v. tijde lang code lopen te refactoren om alle inline JDBC based SQL uit de Java classes te halen en te verhuizen naar hun eigen files. Nu met JPA echter gaat iedereen weer lekker queries in de Java code zetten. Zij het deze keer niet direct in een String, maar als meta data.

Queries buiten de .java bestanden .

[ Voor 39% gewijzigd door Confusion op 13-02-2008 08:43 ]

[JKVA]

Ik zie het persoonlijk iets minder zwart-wit. Annotaties hebben wel degelijk nut. De EJB 3.0 (niet JPA) en Spring annotaties voor resource injectie en bean lifecycle management vind ik persoonlijk erg fijn.

Ook het maken van een web service is tegenwoordig triviaal en dat is weleens anders geweest.

Ook JPA en Hibernate annotaties hebben wel degelijk nut. Zo staan je annotaties precies naast de properties waarop ze van toepassing zijn en bijvoorbeeld bij prototypen is het heel handig.

Bovendien, hoe vaak verandert je datamodel zonder dat je domeinmodel mee verandert?

Persoonlijk trek ik de scheidslijn liever anders, namelijk omgevingsspecifieke properties buiten de applicatie en de rest erin. Ofwel, de Hibernate connectiegegevens buiten de applicatie en de mappings erin.

Maar het blijft natuurlijk een beetje persoonlijke voorkeur.

[Alarmnummer]

JKVA schreef op woensdag 13 februari 2008 @ 08:56:
Ik zie het persoonlijk iets minder zwart-wit. Annotaties hebben wel degelijk nut. De EJB 3.0 (niet JPA) en Spring annotaties voor resource injectie en bean lifecycle management vind ik persoonlijk erg fijn.

Dependency injection via annotations is gewoon een verkapte vorm van resource locator ipv dependency injection. Ik zal hier straks iets verder op in gaan.. eerst naar kantoor.

[JKVA]

Alarmnummer schreef op donderdag 14 februari 2008 @ 07:49:
[...]

Dependency injection via annotations is gewoon een verkapte vorm van resource locator ipv dependency injection. Ik zal hier straks iets verder op in gaan.. eerst naar kantoor.

Alvast een eerste reactie. Theoretisch heb je gelijk dat de annotatie op de klasse/methode/prop ligt, waardoor het meer van een servicelocator structuur wegheeft. Aan de andere kant ligt de daadwerkelijke mechaniek in de container, waardoor je code alsnog de voordelen heeft die het met dependency injection zou hebben.

Een annotatie @resource vind ik namelijk niet echt obtrusive.

Maar ik geef ook direct toe, ik heb ook liever XML voor Spring bean definities.

[Verwijderd]

Ik werk nu met JPA en JPA lijkt heel erg veel op Hibernate. Je kunt goed zien dat Hibernates aan JPA hebben meeontwikkeld. Op blogs lees je dat je met Hibernate wel meer kunt dan met JPA, hoewel ik er zelf nog niet tegen aan gelopen ben. Velen wachten dan ook liever op de volgende versie van JPA waar dat ook allemaal in zou zitten. Met Hibernate wijk je toch niet ver af van wat in je JPA-standaard zit of zal komen. De beestjes hebben soms net een andere naam, veel meer is het niet.

JPA1.0 voldoet voor wat ik wil prima en mocht ik me gaan ergeren aan Hibernate omdat ze voor postgres weer eens iets niet goed hebben geimplementeerd oid, dan kan ik nu zo omswitchen naar toplink (implementeerd ook JPA) (en dan waarschijnlijk weer tegen honderden andere dingen aanlopen ).

Annotations VS XML zou ik niet te lang naar kijken. Het went allebij even snel en het andere lijkt altijd omslachtiger dan hetgeen waarmee je werkt. Bij JPA kun je ook voor XML-configuratie kiezen en je kunt annotation-configuratie overschrijven met XML-configuratie.

[whoami]

-FoX- schreef op dinsdag 12 februari 2008 @ 21:26:
[...]

Tweede keer bij deze

[...]

Zesde keer bij deze.

Maar aangezien ik verder niets met Java doe, hou ik me hier verder buiten.

[ Voor 19% gewijzigd door whoami op 14-02-2008 09:16 ]

[JKVA]

Verwijderd schreef op donderdag 14 februari 2008 @ 09:11:
Ik werk nu met JPA en JPA lijkt heel erg veel op Hibernate. Je kunt goed zien dat Hibernates aan JPA hebben meeontwikkeld. Op blogs lees je dat je met Hibernate wel meer kunt dan met JPA, hoewel ik er zelf nog niet tegen aan gelopen ben. Velen wachten dan ook liever op de volgende versie van JPA waar dat ook allemaal in zou zitten. Met Hibernate wijk je toch niet ver af van wat in je JPA-standaard zit of zal komen. De beestjes hebben soms net een andere naam, veel meer is het niet.

JPA1.0 voldoet voor wat ik wil prima en mocht ik me gaan ergeren aan Hibernate omdat ze voor postgres weer eens iets niet goed hebben geimplementeerd oid, dan kan ik nu zo omswitchen naar toplink (implementeerd ook JPA) (en dan waarschijnlijk weer tegen honderden andere dingen aanlopen ).

Annotations VS XML zou ik niet te lang naar kijken. Het went allebij even snel en het andere lijkt altijd omslachtiger dan hetgeen waarmee je werkt. Bij JPA kun je ook voor XML-configuratie kiezen en je kunt annotation-configuratie overschrijven met XML-configuratie.

Hibernate is ook gewoon een JPA implementatie vanaf versie 3.nogwat.

Je kunt dus gewoon op een JPA manier werken, voor zover de JPA spec dat toestaat. De entitymanager kun je gewoon gebruiken voor persist, load, etc. Ook is het slim om qua annotaties jezelf te beperken tot die in javax.persistence.

Voor Hibernate specifieke zaken, zoals 2nd level cache, criteria API etc kun je per geval terugvallen op Hibernate.

Dat maakt een migratie in de toekomst gemakkelijker.

[Verwijderd]

JKVA schreef op donderdag 14 februari 2008 @ 11:02:
[...]

Hibernate is ook gewoon een JPA implementatie vanaf versie 3.nogwat.

Je kunt dus gewoon op een JPA manier werken, voor zover de JPA spec dat toestaat. De entitymanager kun je gewoon gebruiken voor persist, load, etc. Ook is het slim om qua annotaties jezelf te beperken tot die in javax.persistence.

Voor Hibernate specifieke zaken, zoals 2nd level cache, criteria API etc kun je per geval terugvallen op Hibernate.

Dat maakt een migratie in de toekomst gemakkelijker.

Ja, wat ik bedoelde te zeggen is dat toen Sun aan JPA ging ontwikkelen ze een paar Hibernate-ontwikkelaars er bij hebben gepakt, met als gevolg dat de JPA-api en de JPA-mogelijkheden heel erg lijken op wat je met eerdere versies van Hibernate al kon. Het verschil is dus niet zo heel erg groot.

en je kunt inderdaad JPA implementeren en zo nu en dan terugvallen op het onderliggende, hoewel dat laatste natuurlijk alle voordelen van JPA boven een specifieke ORM tenietdoet. Echter, wat je nu nog wel met hibernate kan en niet met JPA, kun je in de toekomst waarschijnlijk ook met JPA. Wat dat betreft kun je nu wellicht beter JPA over Hibernate draaien dan JPA over Toplink o.i.d. Mocht je nog terugvallen op iets ORM-specifieks is dat later waarschijnlijk het makkelijkst om te schrijven naar de nieuwe versie van JPA.

[ Voor 15% gewijzigd door Verwijderd op 14-02-2008 12:27 ]

[JKVA]

Verwijderd schreef op donderdag 14 februari 2008 @ 12:24:
[...]
en je kunt inderdaad JPA implementeren en zo nu en dan terugvallen op het onderliggende, hoewel dat laatste natuurlijk alle voordelen van JPA boven een specifieke ORM tenietdoet.
[...]

Mwah, het heeft nog steeds voordelen.

Bij JSF val je ook weleens terug op specifieke code, zoals van MyFaces of Trinidad. Dat maakt JSF niet overbodig, want het grootste deel is gestandaardiseerd.

Zo zie ik het bij JPA en Hibernate ook. Mocht JPA nieuwe features krijgen, dan migreer je je Hibernate specifieke code naar JPA. En daarop voorsorteren door zoveel mogelijk gebruik te maken van JPA klassen/annotaties/deployment descriptors zorg je ervoor dat het veel minder werk is met veel minder risico.