JPApi #

Soll eine Bibiothek für eine "Java Persistenz API" werden, die flach und einfach ist,

Ziele, die man erreichen sollte #

• kompatibel mit JDK >= 1.5
• wenige bis hin zu gar keinen Abhängigkeiten
• Möglichst wenig Konfiguration
• Annotationen an der vorhandenen API von Sun orientieren
• unsere API an der API von Sun orientieren
• kurze Ladezeit (im Vergleich z.B. zu Hibernate)
• so weit wie möglich Nutzung vorhandener APIs (z.B. BeanInfo, PropertyDescriptor, Collections wie List oder Set, etc.)

Features #

• Mapping
• Caching (PREPARED Statement)
• Connection POOL
• Konfiguration durch Java Quellcode, Konventionen, Annotationen, Konfigurationsdateien, vorhandene Datenbank (in dieser Reihenfolge)
• Im Normalfall stehen alle Eigenschaften einer Bean in einer einzigen Datei (im Java-Quelltext)
• automatische Erstellung von GUIs (Web und Swing)
• Arbeit mit mehreren Datenbanken gleichzeitig (mit übergreifenden Fremdschlüsseln)
• Caching von Metainformationen

Observer-Pattern (Wikipedia) #

• Änderungen werden direkt in der Datenbank gemacht
• Die Observer-Funktionalität sollte automatisch in vorhandene Beans eingebaut werden (läuft übrigens bereits bei ThomasBayen mit BCEL)
  • BCEL (http://bcel.apache.org) - Bytecode-Manipulation, wird von vielen bekannten Projekten genutzt
  • SERP (http://serp.sf.net) - Alternative zu BCEL
  • Jasmin (http://jasmin.sf.net) - Bytecode-Assembler
  • AspectJ (http://www.eclipse.org/aspectj) - aspektorierentiertes Java
  • Proxy-Objekte (http://java.sun.com/j2se/1.5.0/docs/api/java/lang/reflect/Proxy.html) - Lösung aus dem JDK
• Es sollte möglich sein, den Observer auch selbst zu implementieren (ganz ohne BCEL) - das macht dessen Funktionsweise transparenter.

Design-Entscheidungen #

Hier möchte ich kontroverse Dinge sammeln bzw. Entscheidungen dokumentieren, die nicht sofort offensichtlich sind.

Wie direkt ist die Verbindung zur Datenbank? #

Eine Möglichkeit ist es, unabhängige Beans (mit Fremdschlüsseln ggf. einen Beanbaum) zu laden. Diese werden dann frei bearbeitet und werden mit einer update-Methode wieder zurückgeschrieben. Das andere Extrem ist es, wenn jeder getter und setter der Bean direkt auf einen SQL-Befehl gemappt wird. Zwischenlösungen sind denkbar. Für verschiedene Probleme sind verschiedene Bindungsstärken sinnvoll. Was sollte nun wirklich implementiert werden?

Was nimmt man für die Modifikation der Beans #

• Die o.g. Bytecodegeneratoren können unser Problem wohl alle lösen. Allerdings ist die Codeerzeugung alles andere als intuitiv und einfach. Andererseits kann man durch Delegation dazu kommen, daß man die eigentliche Funktionalität wieder in richtigem Java schreiben kann. Man kann die persistente Klasse als Ableitung der Original-Beanklasse implementieren. Wenn diese Lösung einmal steht (ich habe es bereits mit BCEL gemacht), ist sie eigentlich ganz gut.
• Proxy-Objekte bauen auf einem Interface statt auf einer Bean-Class auf. Man müsste also zu jeder Beanklasse ein identisches Interface haben. Vielleicht erstellt man dieses per BCEL? Es entsteht dann das Problem, daß das Proxy-Objekt nicht mehr die Klasse der ursprünglichen Bean hat. Das kann zu Verwirrung führen. Hibernate scheint so zu arbeiten, da mir dort genau dieses Problem aufgefallen ist.
• AspectJ ist garantiert die eleganteste und intuitivste Lösung. Scheinbar kann man es neuerdings sogar dazu bringen, in einer Standard-Umgebung zu laufen (ohne Precompiler). Es erlaubt aber leider nicht, zusätzliche Methoden in einer Klasse zu erzeugen. Es modifiziert immer die Originalklasse, d.h. auch nicht-persistente Instanzen der Klasse werden verändert.

Was ist eine Bean? #

• BCEL nutzen um Klassen zu bearbeiten, Event handling

public class Bean {

    private Feld a;

    public Feld getA()  { return a; }
    public setA(Feld b) { a = b;   }
}

Links #

• offizielle FAQ zu JPA von Sun
• Artikel von Sun über JPA

Kategorien

KategorieJava