Menu
▾
▴
RE: [Springframework-developer] Hibernate and JDO support
|
From: <jue...@we...> - 2003-04-15 16:08:11
|
Well, "OP"... it isn't a well-known abbreviation. Is "Object = Persistence" the first thing that comes to your mind when you read "OP"? = Of course, we could still adopt it if we can't come up with a better = term. I really like Hibernate - although like everything, it isn't perfect: = For example, the root HibernateException is derived from Exception, not = RuntimeException (one more reason for HibernateTemplate, it transforms = them to ones derived from Spring's DataAccessException)... Hibernate has a much more sophisticated query language than standard = JDO, and a general simpleness in terms of configuration (I guess O/R = mapping XML files cannot be significantly simpler) while still providing = very powerful features (targetted at and optimized for relational = databases, in constrast to JDO). Like TopLink and OJB, it uses = reflection for dirty checking, instead of JDO's bytecode manipulation = approach. And in contrast to JDO, it moves very fast: 1.0 in July 2002, = now 1.2.4 resp. 2.0 beta 4... (We're successfully using the 2.0 tree, = providing a polished API and numerous new features, for werk3AT = projects). I wouldn't tie Spring to Hibernate: There are viable alternatives like = TopLink, Apache OJB, and some JDO implementations. Generally, we need a = clear distinction between when Spring's jdbc package is appropriate and = when an O/R mapping toolkit starts to make sense. Simply put, if an = application has a lot of entities with typical CRUD on the single object = level and somewhat straightforward mapping to database tables, then O/R = mapping seems appropriate. But of course, the decision isn't as simple = as that - there are lots of issues to consider. Mixed usage of plain JDBC, JdbcTemplate, Hibernate, JDO, whatever in = data access services isn't a problem when using J2EE DataSources for = JDBC Connection acquisition underneath, and JTA for transaction control. = There are some quirks like JTA TransactionManager lookup for = synchronized cache updates, but they can be solved with a = server-specific lookup strategy or by using a J2EE Connector for the = persistence toolkit (Hibernate supports both, although the Connector = support isn't stable yet). Obviously, a single way of handling data access to a single datasource = leads to a less complex application, with the option of achieving = high-level transaction control via a specific PlatformTransactionManager = implementation (and a non-XA DataSource underneath, like I proposed for = Hibernate) instead of JtaTransactionManager (and an XA DataSource). That = way, web apps that need to run on plain Tomcat with its built-in non-XA = JDBC DataSource support (without a Tyrex add-on for JTA support) can = still benefit from clear transaction control. And the application code = can be reused in a JTA/XA environment without any changes. The ThreadLocal approach could also be applied to a pooled JDBC = Connection retrieved via a standard DataSource, provided that resource = lookup works with JdbcTemplate or a specific helper (to check for an = existing ThreadLocal Connection, analogous to HibernateTemplate). Note = that such a JdbcConnectionTransactionManager (capable of working with = any DataSource) would be different to the existing = SingleConnectionTransactionManager, as the latter's DataSource doesn't = pool at all (it is only suitable for unit tests and standalone = applications). BTW, have you noticed that the names "Hibernate" and "Spring" allow some = nice wordplays like "reactivate your hibernating data in spring"... ;-) Juergen -----Original Message----- From: Isabelle Muszynski [mailto:isa...@me...] Sent: Tuesday, April 15, 2003 3:43 PM To: spr...@li... Subject: Re: [Springframework-developer] Hibernate and JDO support what about op? does hibernate work really well? should we use it exclusively? see = juergen's previous mail about maybe not wanting to do everything. Isabelle On Tue, Apr 15, 2003 at 12:07:01PM +0200, j=FCrgen h=F6ller [werk3AT] = wrote: > Hi everyone, >=20 > Here at werk3AT, we are using Hibernate in combination with Spring = successfully in a current major project: Spring for configuration, = general service infrastructure, validation, and test infrastructure = (mock JNDI + mock JDBC DataSource) - and Hibernate for persistence. We = will add Spring's web MVC and transaction infrastructure soon. >=20 > A HibernateTemplate that applies Spring's callback approach to = Hibernate Sessions - implementing a doInSession(Session) method, without = the need for Session lifecycle and exception handling - helps reducing = glue code significantly. I plan to contribute it to Spring soon, = enriched by a Hibernate implementation of PlatformTransactionManager = (handling transactions via Hibernate's native transaction API for a = single SessionFactory, using a ThreadLocal Session). >=20 > So, would anyone mind a Hibernate JAR in our development lib = directory? I consider a separate module for those few classes overkill, = so I'd like to add them to the main source tree. But what package would = such stuff belong to, maybe "com.interface21.orm.hibernate" (ORM for = Object Relational Mapping)? Our jdbc package is on the same level as the = dao package too, instead of below it, so this should fit the existing = structure. >=20 > A forthcoming JdoTemplate or the like would belong to = "com.interface21.orm.jdo" then. Hmmm, "ORM" isn't too appropriate here, = as JDO isn't restricted to O/R mapping, strictly speaking... but "object = persistence" doesn't have an obvious short name. What's a suitable = generic term for both dedicated O/R mappers like Hibernate/OJB/TopLink = and JDO implementations? Any suggestions? >=20 > Regards, > Juergen >=20 >=20 > DI J=FCrgen H=F6ller > Senior System Architect > ______________________________________ >=20 > werk3ATS - division systementwicklung > part of werk3AT internetmedien oeg >=20 > europaplatz 4 > A - 4020 linz >=20 > t. +43 (0) 732 71 65 29 502 > f. +43 (0) 732 71 65 29 3 > jue...@we... > www.werk3at.com > ______________________________________ > werk3ATS - WIR ENTWICKELN ERFOLG >=20 >=20 >=20 > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer >=20 >=20 --=20 Isabelle Muszynski Software Engineer Zandweellaan 4 2660 Antwerpen Belgium Tel. 32-(0)3-830 18 54 Mobile: 32-(0)485 49 50 89 Email: isa...@me... Website: www.meta-logix.com ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
