Ich baue einen Web-Service mit dem Dropwizard-Framework (Version 0.7.0). Dazu werden einige schreibgeschützte Abfragen an die Datenbank ausgeführt, die Ergebnismenge manipuliert und dann der Datensatz zurückgegeben. Ich verwende MySQL als Datenbankmodul. Da ich neu in diesem Framework bin, möchte ich wissen, welche Option ich wählen sollte: Hibernate oder JDBI.Hibernate vs JDBI
Ich habe beide verwendet. Ich habe Hibernate mit GORM sowohl in Grails als auch in einer herkömmlichen Spring-App verwendet, und ich habe JDBI in Dropwizard verwendet.
Ich habe die Einfachheit von JDBI wirklich genossen und hier sind ein paar Gründe, warum ich es über Hibernate bevorzuge.
Ich weiß genau, was SQL ausgeführt wird, um die Daten zu erhalten, die ich anfordere. Mit Hibernate können Sie manchmal viel mit HQL herumspielen und Ihre Objekte so konfigurieren, wie Sie es erwartet haben. Sie greifen schließlich auf SQL zurück, haben dann aber die Schwierigkeit, Ihre Ergebnisse ordnungsgemäß auf Ihre Domänenobjekte zuzuordnen, oder Sie geben auf und lassen zu, dass Hibernate sie nacheinander abruft.
Ich brauche mir keine Sorgen über das Faul/Eager-Fetching zu machen und wie sich das auf die Abfragezeit großer Datensätze auswirkt.
Mappings sind nicht kompliziert, weil Sie sie selbst verwalten und Sie nicht auf die richtigen Kombinationen von Annotationen und Optimierungen angewiesen sind.
Für Ihren Fall insbesondere, es klingt wie Sie leichte etwas wünschen würde, weil Sie nicht viel von Anwendungsfällen haben und das würde auf jeden Fall JDBI über Hibernate meiner Meinung nach sein.
Wenn Sie nur sehr wenig Arbeit an der Datenbank haben, dann verwenden Sie JDBI, sonst gehen Sie für Hibernate, da es sehr stark ist und viele zusätzliche Funktionen für Ihre Persistenzlogik bietet.
Wirklich, beide Lösungen sind nur "lock-in".
Wenn Sie mit einer persistenten Modelltyp-Schnittstelle arbeiten möchten, schreiben Sie Ihren Code gegen JPA (wenn Sie sicher sind, dass er nur in eine relationale Datenbank zurückkehrt) oder JDO (wenn Sie zu relationalen und anderen Projekten zurückkehren möchten) Typ Datenbanken, wie die No-SQL-Bewegung). Dies liegt daran, dass Sie bei einer dieser Lösungen bei Auftreten von Problemen Persistenzanbieter wechseln können, ohne den Großteil Ihres Codes neu schreiben zu müssen.
Wenn Sie mit einem prozeduralen Persistenzmodell gehen wollen (mit SQL-Abfragen direkt und so umgehen), dann gehen Sie mit JDBi oder vielleicht sogar JDBC. JDBi bietet eine sehr schöne Abstraktion über JDBC; Es gibt jedoch Fälle, in denen Sie Zugriff auf die niedrigere Ebene haben möchten (aus Gründen der Leistung, die Sie tun, wenn Sie die Abfragen und die Datenbank gemeinsam abstimmen). Wiederum ist JDBC ein Standard, so dass Sie mit Leichtigkeit eine Datenbank gegen eine andere austauschen können. Das SQL selbst wird jedoch nicht so einfach ausgetauscht werden können.
Um die SQL-Auslagerungsprobleme zu verbessern, empfehle ich, Sets von Eigenschaftendateien zu verwenden, um die Abfragen zu halten, und dann einen Resource Loader-Typ mechanisim, um die SQL für die richtige Datenbank an den Code zu binden. Es ist nicht 100% idiotensicher; aber es bringt dich ein bisschen weiter.
Nun, wenn Sie mich fragen, was ich verwenden würde, empfehle ich JDO.