Hydra schreef op vrijdag 11 september 2015 @ 09:57:
[...]
Dit volg ik niet helemaal. Het opzetten van de verbinding is eenmalig; die blijft actief. Natuurlijk is er een oevrhead in het gebruik van een ORM maar als het goed is valt die in het niets t.o.v. de tijd die het je DB kost de data op te hoesten. Als je ORM zo'n grote overhead geeft zit er iets grondig mis.
[...]
Wel bijzonder. Ik vraag me af wat er fout gaat. Ik ben absoluut geen fan van Hibernate maar standaard CRUD werk doet 't normaliter prima.
In m'n huidige project gebruiken we EclipseLink als JPA provider trouwens.
Ik zou niet weten eigenlijk wat Hibernate allemaal onder water probeert te doen. Wat mij opvalt is dat de tijd die het kost om queries uit te voeren, de resultset te mappen naar je Java objects en te retourneren in ieder geval pakweg 3 tot 4 keer trager is dan bijvoorbeeld ORMLite of Ebean queries.
Ja, het Hibernate framework bevat meer logica (en duizend-en-één meer libraries

) dan ORMLite en Ebean, maar het verschil in snelheid was echt overduidelijk.
Nou moet ik zeggen dat wij op dit moment de laatste versie van Hibernate 3 gebruiken, 4 heb ik alleen thuis gebruikt en na korte tijd ben ik voor mijn eigen gehobby overgestapt naar zelf alle queries schrijven, omdat ik toch niet al teveel DB-interactie nodig heb.
Tja. Ik ben absoluut geen fan van het verplaatsen van business logic naar de DB. M.i. moet je DB als een zo'n dom mogelijke datastore beschouwd worden. Kunnen de queries die jullie gebruiken niet in een view gegoten worden?
Hebben we over nagedacht, maar wat we uiteindelijk doen is alles waar we meer dan CRUD nodig hebben (bijvoorbeeld voor het bouwen van rapporten of het ophalen van complexe object met meerdere foreign keys) een Stored Procedure gebruiken die we zo universeel mogelijk maken. De data die daaruit komt wordt dan weer verder gebruikt in de echte business logica in de code zelf.
[
Voor 23% gewijzigd door
Merethil op 11-09-2015 10:04
]