Spring JDBC vs. Spring Data JPA

Wir haben vor kurzem 'ne Ausschreibung rein bekommen, wo der Kunde kein ORM-Framework möchte sondern lieber “Spring JDBC” nutzen möchte.

Vor ein paar Jahren waren ORM-Frameworks doch der letzte Schrei und jetzt geht der Trend wieder zurück?

Ich hab keinerlei große Lust irgendwo komisch auf ResultSets rumzuturnen um daraus Objekte zu bauen mit denen ich dann weiter hantieren kann.

Hab ich irgendwas nicht mitbekommen oder ist der Kunde irgendwie in der Zeit hängen geblieben?

Es gibt Situationen, an denen ein ORM nicht unbedingt das schnellste ist. Bzw. wenn man weiß, was man tut, kann JDBC schneller sein.

Mir kommt so etwas eher selten unter, weil es meist ein Designproblem innerhalb der DB ist und nicht wirklich das ORM. Eventuell ist bei BigData auch einfach eine relationale DB nicht das richtige.

Vielleicht hat der Kunde auch einfach viele schlechte Erfahrungen gemacht?

Frag doch einfach warum, vielleicht gibt es ja einen Grund.

ORM-Frameworks haben ja eine lange Historie, anfangs hab ich zum Beispiel noch Hibernate via XML-Konfiguriert, zum Spass dann irgendwann mit XDoclet, frage nicht. Eventuell ist da ja noch jemand auf diesem Stand und schreibt dann lieber SQL statt moderne Annotationen.

Je nachdem wie komplex die Abfragen sind, kann es durchaus sinnvoll sein, via SQL auf die Datenbank zuzugeifen und dort die entsprechenden Ergebnisse rauszufischen.
Wenn allerdings 99,9% so CRUD-Geschichten sind, dann ist ein ORM doch sinnvoll, wobei man ja auch beides verwenden kann.

Wenn du aber einen SQL-Verfechter hören willst, dann kannst du ja mal nach ein paar Vorträgen von Lukas Eder (JOOQ) suchen.

Das kannst Du auch mit einem ORM. Du kannst beliebige Ergebnisse direct in gewünschte Klassen mappen.

Das Haben wir gemacht, die Aussage war in etwa:

„Wir wollen weiterhin mit relationalen Datenbanken arbeiten, da brauchen wir kein ORM“


Es geht im Grunde darum, das die eine alte bestehende Anwendung neu implementiert haben wollen, es ist aber noch nicht geklärt, ob die Datenbank auch neu entworfen soll.

Diese Begründung ist wenig ausreichend.

Genau das dachte ich auch und musste mich beherrschen da nicht laut los zu lachen.


Vielleicht kann man den Kunden noch überzeugen oder er der Kunde kann besser begründen warum kein ORM gewünscht ist. Ich wollte nur erstmal für klären, ob da vielleicht was an mir vorbei gegangen ist.

iBatis hab ich damals dem reinen JDBC bevorzugt, man hat halt mehr Boiler Plate Code zu schreiben ohne vollstaendiges ORM, dafuer kann man viel Optimieren und hat mehr Kontrolle.

JPA ist auf RBMS ausgelegt, es hinkt IMHO auf nicht-relationalen Datenbanken, JDO war da flexibler, aber auch komplexer.

Falls das Schema und die Daten erhalten bleiben sollten, ist das gar nicht so abwegig, ein aus der DB generiertes „Objektmodell“ ist nicht so toll, macht aber nur Sinn wenn das RDBMS Schema schon API ist das von anderen Systemen direkt verwendet wird.
Wenn es aber ein Schema ist dass der Oracle DBA von handoptimiert hat und/oder Stored Procedures die ganze Anwendungslogik enthalten, am besten wegwerfen und die Datenbank wechseln :wink:

1 „Gefällt mir“

Soweit mir bekannst ist, werden keine Stored Procedures verwendet.

Das geile ist auch, ich hab über Ecken erfahren dass der Architekt, der kein ORM möchte gar nicht für dieses Projekt zuständig ist. Es bleibt spannend :popcorn: