commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Max Rudman <>
Subject Re: Commons Mapper: scope/roadmap?
Date Sat, 18 Dec 2004 03:32:10 GMT

On Dec 17, 2004, at 8:52 PM, David Graham wrote:

> There aren't any reusable implementations that I can think of.  What do
> you picture the Hibernate mapper implementation looking like?
Well, I am not too familiar with other O/R implementations but at least 
in Hibernate you don't need a separate Data Access Object (DAO) 
implementation for each value object. Everything needed to persist and 
load Person is captured in Person.hbm.xml mapping file.

What I have in mind for Hibernate implementation is HibernateMapper 
class which will hold on to Hibernate Session object and Class of the 
entity being persisted. HibernateMapperFactory then would simply pass 
through entity class to the Mapper so it can in turn use it in its 
calls to Hibernate Session. It would look something like this:

public class HibernateMapper implements Mapper {
   private net.sf.hibernate.Session session;
   private Class type;

   public HibernateMapper(Session session, Class type) {
     this.session = session;
     this.type = type;

   public Object findByUniqueId(Object id) {
     return session.get(type, id);



This is probably very oversimplified and there is a fair amount of 
"housekeeping" code; hence, the value of providing an implementation as 
part of the Mapper project instead of forcing users to re-invent the 
wheel so to speak.

In addition, we could provide an implementation which works with Spring 
Framework, for example, which is an IoC container I am very fond of. 
That way, the whole MapperFactory configuration can be done out of XML 
config files and provided to business logic classes in the "Injection 
of Dependency" manner. As a bonus, Spring integrates with Hibernate to 
provide automatic transaction management and such.

I imagine something similar can be done for other O/R frameworks; I am 
just not familiar enough with them to give you more details.

> Mapper really saved me on one project where we designed a new db schema
> and wrote a bunch of code to access it and then mgmt. decided to use 
> the
> old schema at the last minute.  All I had to do was implement the 
> mappers
> differently and the rest of the app. never changed.

I agree, O/R tools are great but being able to switch to a different DB 
schema is a virtue of the O/R mapping tool itself not the abstraction 
API like Mapper. In other words, it seems to me I could have achieved 
the same result by using Hibernate directly as opposed to hard-coding 
DB schema in JDBC calls. If I understood the project's goal correctly, 
it is to abstract various O/R implementations in a manner similar to 
how Commons Logging abstracts various Logging implementations.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message