Hibernate Mapping-File vs. Annotations

[Kessi]

Hi zusammen

Da ich in unserem neusten Projekt eine kleine SQLite-Datenbank auf einem J2ME-fähigen Embedded-Computer ansprechen darf, musste ich den Target-Level meiner Applikation auf 1.3 reduzieren. Da somit Annotations wegfallen, wird z.B aus:

@Entity
public class Reason {
    @SuppressWarnings("unused")
    @Id
    @GeneratedValue
    private int id;
    private String reason;

    public Reason(String reason) {
        this.reason = reason;
    }
}

folgendes hbm.xml-File:
[XML]
<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">

<hibernate-mapping package="com.stoecklin.apat.entity">
<class name="Reason" default-access="field">
<id name="id">
<generator class="native"/>
</id>
<property name="reason"/>
</class>
</hibernate-mapping>
[/XML]

Eigentlich nicht weiter schlimm, nur dass mich 2 Sachen stören:

• Wieso braucht die Reason-Klasse plötzlich einen Default-Konstruktor? Wird im Hibernate-Manual als absolut zwingend angegeben, mit den JPA-Annotations brauchts aber keinen :bahnhof: ...
• Gibt es einen Modus, sodass standardmässig alle Member-Variablen als Properties verwendet werden, ohne dass ich sie explizit im XML namentlich erwähnen muss? Das entspräche ja dem Standardverhalten bei Annotations.

Danke für eine kurze Antwort und beste Grüsse
Kessi

 

[maki]

Seit wann läuft Hibernate auf J2ME?
Gibt es da überhaupt JDBC?

 

[Kessi]

Seit wann läuft Hibernate auf J2ME?
Gibt es da überhaupt JDBC?

Jein. Es gibt eine JDBC-Erweiterung für J2ME, im Package javax.sql anstatt java.sql. Hibernate kann problemlos mit javax.sql.DataSource statt java.sql.DataSource umgehen. Das Problem ist meistens nur, eine Datenbankimplementierung zu finden, die javax.sql.DataSource implementiert (und zwar J2ME-kompatibel - manche DBs implementieren javax.sql, verwenden intern aber J2SE-Klassen). H2 war bisher so eine Datenbank, in der neusten Version hatte ich allerdings bereits wieder Schwierikgeiten.

 

[nocturne]

Hallo Kessi,

ich empfehle Annotationen weil diese z.B. ohne großen Aufwand auszulesen sind. Die Archive werden kleiner, der Codewusel ist übersichtlicher. Annotationen sollen solche Configuration-XML's ersetzen!

Also die alten Hasen kümmern sich darum nicht. Die verwenden ant
Chapter4.Ant Tools
(4.2.1)

Die Profis verwenden MS Visio oder noch fieseres.

 

[KSG9|sebastian]

Hm...ich bin immer noch für die gute XML-Datei.

Warum? Weil's deutlich schneller ist (wir haben diverseste Messungen in Großprojekten getätigt), die persistenten Klassen haben keine direkten Abhängigkeiten auf Hibernate und so viele Annotations machen den Code unübersichtlich. XML kann ich generieren lassen, deployen wann ich will, ohne neuen Build u.s.w.

Zu deinem Problem: Defaultkonstruktor ist nicht notwendig.

Geht:

class X{

}

Geht:

class X{
   public X(){

   }
}

Geht nicht!!

class X{
   public X(int y){

   }
}

Hibernate benötigt nur einen No-Arg-Konstruktor. Ob implizit oder explizit ist egal.