ejb 3.0 vs. jdo vs. hibernate vs. iBatis

Hi,

Hab recht viel (reallife-projekt) Erfahrungen mit ejb 3.0 & "O/R-Mappern" gesammelt.
Für eine halbwegs sinnvolle/ausführliche Antwort (pro/kontra ejb 3.0 bzw OR/M bzw OO-DBs) fehlt mir allerdings atm die Zeit
Werde mich dann in ein paar Tagen in die Diskussion "einklinken", soferne es eine gibt
Sollte ich stressbedingt vergessen -> Mail / PM = np

mfg,lb

Jo, des ist nicht leicht zu durchblicken
Die Schwierigkeit liegt da natürlich auf vielen Ebenen möglichst bunt vermischt.

Zitat

nachdem ich mir nun das thema ejb 3.0 jpa genauer angesehen habe, würde mich auch interessieren, ob ich diese api auch für eine rcp anwendung mit j2se verwenden kann.

Vorausgesetzt das hier ist gemeint:
(3.0'er) Entitybeans "Embedded"/"Containerlos"/"Unmanaged"/"Lokal"/"In nicht J2EE Umgebung" verweden zu können.

Ja, das geht definitiv.
Soweit ich mich erinnern kann ist das sogar ziemlich trivial, der einzige Unterschied zum Deployment der EBs in einem EJB3 Container sind ein paar Änderungen im persistence.xml file.

Was dann bleibt ist quasi ein "Vereinfachtes Hibernate".
(bzw welches OR/M tool die jeweilige JDA Impl. auch immer verwendet, bei Hibernate ist's IMHO jedenfalls eine deutliche Vereinfachung)

In diesem Zusammenhang ist überingens JBoss' embeddable-EJB3-Container ziemlich interessant.
(zumindestens die Idee/der Ansatz, leider dzt noch "unbrauchbar alpha")

Zitat

jetzt bin ich wieder etwas schlauer: die ejb 3.0 spezifikation JSR-220 spezifiziert ja die java persistant api. hibernate setzt ja genau das mit hibernate entitymanager und hibernate annotations um. also eigentlich kann man ja dann hibernate und ejb 3.0 jpa nicht so 1:1 vergleichen, oder?

Genau.

to be continued whenever more time .... (sh***y post-vacation week)

the continuation:

Ob OR/M überhaupt möglich ist, hängt von der konkreten Anwendung ab.
Klingt komisch, ist es auch, denn möglich ist der Einzsatz von ORMs immer.
Diese überspitzte Formulierung soll verdeutlichen, daß es Objektmodelle gibt, mit denen
ORM grundsätzlich sehr problematisch ist.
Grundsätzlich heißt, daß es da tool/implementierungs unabhängige Probleme gibt.
Nennen wir es "OR-mismatch"
Ich meine damit nicht die bekannten Dinge wie: wie bilde ich Polymorphie auf RDBS ab,
sondern Performanceprobleme.
Nicht möglich soll also heissen: kein laufzeiteffektives Mapping möglich.
(uneffektiv heißt hier praktish nicht verwendbar)
Da sind übliche Performancetweaks wie lazy-loading, n+1 selects avoidance,
diverstestes Caching-Strategien schon inkludiert.
Komplexe Objektmodelle wo jedes Objekt von jedem abhägt,
möglichst tief, möglichst viele, ... sind dafür besonders anfällig.
(Objekt hat "Kindobjekte", welche wiederum Kindobjekte hat, welche wiederum ...)

Diese grundsätzlichen Probleme zu erwähnen ist imho wichtiger als Details der
verfügbaren OR-Mapper zu diskutieren.
Insbesondere weil es gerne (eigentlich immer) verschwiegen bzw unbekannt ist.

Erfahungsgemäß: Hat man Performanceprobleme mit ORM
(und die üblichen Tricks a la lazy-loading helfen nix),
nützt ein Tausch des ORMs nichts.
(wahrscheinlich ein ungünstiges Objektmodell für ORMs)

EJB 3.0: IMHO recht genial und durchaus gelungen ...
Komplexere Mappings für die ich mit reinem Hibernate Tage gebraucht hab
gehen in Stunden/Minuten von der Hand ...

Nachteil: Sieht alles recht eazy aus, hat aber leider eine Menge versteckter
Komplexitäten -- ORM sei dank.

ibatis ist interessant, aber für mich kein ORM.

Wenn's denn eine reine objektorientierte DB sein darf -> db40 ansehen.

Oki, Ende des Monologs.