haben die zwei generischen Parameter T und I noch etwas zu sagen oder steht GenericiBatisDao auf einer Stufe parallel zu HibernateGenericDAO?
da dürfte es schlecht aussehen, Basisklassen kann man nicht mal eben austauschen,
auch Generics ganz außer Acht gelassen,
nimm eine einzelne Klasse X extends HibernateGenericDAO, die kann nicht auf einmal die Methoden wechseln
begrenzt geht es mit einer Multi-Basisklasse, die alles mögliche auf sich vereint, dabei drei Interface implementiert,
class MultiDAO<I> implements HibDao<I>, IbaDao<I>, usw.
dann kann man mit Interface arbeitend halbwegs zurecht kommen, denke ich,
problematisch wird es, falls eine allgemeine Methode wie save(I) in mehreren Frameworks vorkommt,
ich fürche dann muss es eine interne Fallunterscheidung geben:
es ist irgendwo konfiguriert was gerade ‘aktiv’ ist, es muss ja auch eine Session oder ähnliches zur Verfügung stehen,
danach das Framework entscheiden und dann den passenden Code ausführen,
habe ich selber noch nicht gemacht, vielleicht wenig praktikabel
mein Tipp: lieber Datenklassen komplett frei von Frameworks,
Logikklassen mit bestimmten zusammenhängenden Aktionen zu einzelnen Datenarten mit allgemeinen framework-unabhängigen Befehlen formulieren (*),
save() und Co. in Basisklassen definiert,
an dieser Stelle dann den Code, verlinke Implementierungsklasse austauschen
was nützt dir überhaupt verschiede DAOs?
Code wie ‘lade Bild, speichere Bild in Posting zu User’ will man doch nicht je nach DB mit anderen DAO-Befehlen neu programmieren?
(*) böse formuliert schafft man damit freilich einen neuen Standard…
[spoiler][/spoiler]