= 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|http://de.wikipedia.org/wiki/Beobachter_%28Entwurfsmuster%29]) ==

* Ä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
* 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 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|http://java.sun.com/javaee/overview/faq/persistence.jsp]
* [Artikel von Sun über JPA|http://java.sun.com/developer/technicalArticles/J2EE/jpa/]

----
;Kategorien:KategorieJava