Alternative zu Hibernate

[goldi345]

Hallo zusammen,

auf der Suche nach einer Alternative zu Hibernate bin ich auf die Persistenzkomponente Empire-db (http://www.empire-db.org) gestoßen. Das Beispiel und das Tutorial haben mir gut gefallen.

Hat jemand von euch schon Erfahrungen mit Empire-db? Was haltet ihr davon?

Liebe Grüße,
Ines

[Waxolunist]

Ich finde auf der Seite jetzt keinen Weg, wie ich einfach an meine Objekte rankomme und ein SQL-Statement liest sich meiner Meinung nach leichter als

SampleDB db = getDatabase();
// Declare shortcuts (not necessary but convenient)
SampleDB.Employees EMP = db.EMPLOYEES;
SampleDB.Departments DEP = db.DEPARTMENTS;
// Create a command object
DBCommand cmd = db.createCommand();
// Select columns
cmd.select(EMP.EMPLOYEE_ID);
cmd.select(EMP.LASTNAME.append(", ").append(EMP.FIRSTNAME).as("NAME"));
cmd.select(DEP.NAME.as("DEPARTMENT"));
// Join tables
cmd.join (DEP.DEPARTMENT_ID, EMP.DEPARTMENT_ID);
// Set constraints
cmd.where(EMP.LASTNAME.likeUpper("Foo%"));
cmd.where(EMP.RETIRED.is(false));
// Set order
cmd.orderBy(EMP.LASTNAME);
cmd.orderBy(EMP.FIRSTNAME);

Dieser Code ist auch nicht wie versprochen safe zur Compilezeit. Das ist ja fast one step back, denn dieser Code ersetzt nur ein SQL-Statement, Objekte mit Business Logic muss ich noch immer selbst mappen. Das soll doch bitte mein Framework machen.

Viel besser finde ich da den MS-Ansatz LINQ. JDBC4 erfüllt alles was Empire-DB kann. Ich könnte mir kein Projekt vorstellen, in dem ich Empire-DB sinnvoll verwenden könnte, wo ich sagen kann, dieses Framework erleichtert mir am ehesten noch die Arbeit.

Just my 2 cent

lg, Christian

[rdausk]

Den MS-Ansatz von LINQ finde ich auch sehr gut aber das ist ja genau das was auch Empire-db erreichen will, nämlich die Definition von SQL-Statements über Objektreferenzen statt über Strings. Und genau deshalb ist der Codeabschnitt den Du abgedruckt hast auch Compile-Time sicher, denn wenn sich die Datenmodellbeschreibung ändert, dann bekommst Du vom Compiler einen Fehler. Bei JDBC4 kann ich so was übrigens nicht erkennen, da dort die SQL-Statements über Annotations in Form von Strings hinterlegt werden. Damit bekommst Du aber spätestens dann Probleme, wenn Du abhängig von bestimmten Bedingungen einzelne Constraints und Joins einbauen musst oder nicht, also deine SQL-Statements dynamisch aufbauen musst; oder eben wenn sich Dein Datenmodell ändert und Du den ganzen Code prüfen musst, ob er von der Änderung betroffen ist.

Mit dem Objektmapping hat der Code gar nichts zu tun. Wenn Du darüber Business Objekte füllen willst, dann stellt sich natürlich zuerst die Frage, wie diese aufgebaut sind. Sind es zum Beispiel einfache Java Objekte mit Gettern und Settern (POJOs) dann musst Du dem angegebenen Code nur folgende drei Zeilen hinzufügen:

DBReader reader = new DBReader();
reader.open(cmd, conn);
List<EmployeeInfo> emplList = reader.getBeanList(EmployeeInfo.class);
Noch besser ist es aber, wenn Du dynamische Objekte verwendest und diese direkt von DBRecord ableitest. Dann kannst Du Dir dein Business-Objekt direkt vom DAO Objekt (Tabelle, View) füllen lassen:

Connection conn = getConnection();
Employee emp = new Employee();
EMPLOYEES.readRecord(emp, 4711, conn);

Wobei hier 4711 die Employee ID wäre. Willst Du dann z.B. die Telefonnummer ändern und das Objekt speichern, dann schreibst Du:

emp.setValue(EMPLOYEES.PHONE_NUMBER, "0777/12345");
emp.update(conn);

Wie Du siehst, brauchst Du hierzu kein Command Objekt und musst das SQL dafür auch nicht selbst definieren.

Wenn Du also sagst, dass Empire-db Dich nicht sinnvoll unterstützt, dann musst Du auch sagen wie Du es sonst machen willst – am besten mit konkreten Beispielen. Natürlich kann man alles zu Fuss mit JDBC machen aber warum gibt es dann Datenpersistenzkomponenten wie Hibernate, TopLink und eben Empire-db überhaupt? Ich denke die Antwort kann ich Dir auch geben: Weil eine Datenpersistenzkomponente auch Dinge wie DBMS-Unabhängigkeit, identity management, optimisitc Locking und dirty field checking für optimierte Update/Insert Operationen bieten muss. JDBC alleine kann das nicht und soll das auch nicht können.