A Java atyja csatlakozott a Google-höz

Mi pár rokon nagy projekten használunk hibernate-et. Távol álljon tőlem h azt mondjam, hogy nagy guru lennék, de ez eleve gond az általam eddig látott projekteknél -- ti. adatbázis kezelési ismeretekkel fel vannak általában vértezve az emberek, de a h3-hoz gyakorlatilag teljesen újra kell tanulni az egészet, és ezt magas szinten viszonylag kevesen művelik. Ha ez nincsen meg, akkor már középtávon is szopóág van.

Ha egy jdbc-szerű perzisztencia réteg írása/használata/supportja x tudást igényel, akkor a h3 az gyakran 2x-et. Főleg a bugfix/support van leginkább a rémálom kategóriában, és emiatt eléggé nagy önbecsapásnak tartom a magas szintű perzisztenciát/ORM-et. Ráadásul igazán nem is tud DB-független lenni, mert míg az egyszerűbb esetekben is minimum bele kell túrni a konfigurációba, később HQL-ben is találtok különbségeket/hiányosságokat, és többször volt már olyan, hogy saját dialect-et kellett készíteni.

Nem láttam még igazán jó megoldást DB-függetlenségre. Van aki a tárolt eljárások híve -- ami szintén nem kezdő szint -- van aki több DAO réteget tart naprakészen. A tárolt eljárások mellett szól a teljesítmény, de szétaprózza a kódot, és kell pár progzó, aki ehhez is ért.

Rémlenek valami szinkronizációs problémák is, de az elsődleges ok a teljesítmény.
Nincs annyi kód és annyi ember, hogy rettentően kelljen az absztrakció meg az autoconfig.
--
Gábriel Ákos

Bevallom én nem értem a többiek problémáit. Évek óta használom a hibernate-t több projektben is (régebben hbm.xml-lel és spring dao-val, újabban JPA2 apin keresztül, de spring támogatással) és eddig semmi problémám nem volt vele. Ezek között volt olyan "egzotikus" is, ahol régi alkalmazást kellett portolni, ezért ResultTranformer-t kellett alkalmazni és criteria/HQL helyett jó kis nyers SQL-t (dinamikus táblanév választás és elég összetett sql queryk), de a hibernate itt is nagy segítség volt. Ilyeneket is meg lehet vele tenni:

final SQLQuery query = session
		.createSQLQuery("SELECT {a.*}, {b.*}, {c.*} FROM "
				+ aTableName
				+ " a, "
				+ bTableName
				+ " b, "
				+ cTableName
				+ " c WHERE a.b = ? AND a.u = ? AND a.a = ? AND b.u = a.u AND b.bh = a.b AND c.b = a.b");
query.addEntity("a", A.class);
query.addEntity("b", B.class);
query.addEntity("c", C.class);
query.setString(0, b);
query.setString(1, c);
query.setString(2, a);
query.setResultTransformer(Transformers
		.aliasToBean(Result.class));
query.setMaxResults(1);
result = (Result) query.uniqueResult();

Ahol a Result osztály egy összefogó eredmény A, B, C típusú mezőkkel (A, B, C tábláknak kb. 110 oszlopuk van összesen). A fenti példa elég sok gépeléstől ment meg és igazából nem más fű alatt mint plain JDBC.

De lehet használni sima springet is jdbc-vel. Az is sok gépeléstől ment meg, de nem annyitól, mint a hibernate. Ez esetben a JDBCTemplate és a különböző RowMapper jön jól (pl.: ParameterizedBeanPropertyRowMapper).

Személyes tapasztalat, hogy a Hibernate/Toplink/JPA-val semmi baj nincs, és nagyjából mindent meg lehet velük csinálni - viszont vannak olyan dolgok (tipikusan pl. nagymennyiségű adatokból összefoglalók készítése), amelyekre nem optimális. Ezekre jobb szimplán a JDBC, vagy ha szereted a Spring-et, akkor annak a template-je.