Menu
▾
▴
springframework-developer
|
From: Thomas R. <tri...@tr...> - 2003-04-15 16:05:45
|
Jürgen, How about OPM for Object Persistence Mapping? That would cover O/R Mapping as well as JDO. I don't mind an hibernate.jar at all. It is the best open source O/R mapping framework from what I have seen so far. Looking forward to seeing your HibernateTemplate. Thomas > Hi everyone, > > 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. > > 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). > > 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. > > 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? > > Regards, > Juergen > > > DI Jürgen Höller > Senior System Architect > ______________________________________ > > werk3ATS - division systementwicklung > part of werk3AT internetmedien oeg > > europaplatz 4 > A - 4020 linz > > 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 > > > > ------------------------------------------------------- > 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 > > -- Thomas Risberg tri...@tr... |
|
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 |
