JDBC RowMapper and foreign keys

[romanf]

When mapping a row from a ResultSet, how should I handle foreign keys that represent domain objects?

Example: When loading a row from the Order table, there is a FK to the Customer table. I would like the Order object that is returned by OrderRowMapper.mapRow() to have a fully populated Customer object rather than just an integer FK.

I see two ways to do this:
1. give the RowMapper a reference to CustomerDAO so it can populate the Customer object immediately when FK is retrieved.

2. rewrite the SQL query so it JOINs the customer table and returns customer data as well. Instantiate a new Customer object within OrderRowMapper.mapRow() and call all the setters with customer data from the ResultSet.

Neither of these options seems very clean. (1) is bad from a performance standpoint; now there are two separate DB calls to populate the data. Or even more, since the CustomerRowMapper might be doing the same thing with some of it's FKs. (2) is faster but now the logic for loading Customer objects is no longer centralized in the CustomerDAO.

Does anyone have a better solution or opinion about these ideas? Of course, Hibernate is the best answer but political constraints force me to go with JDBC.

Thank you!
Roman

[Rod Johnson]

Consider iBATIS if Hibernate is politically unacceptable. It's excellent for reading domain objects, has less impact than adopting a true O/R mapping framework, and is Apache License, in case the issue is Hibernate's LGPL, which scares some companies.

[romanf]

Thanks for the advice, Rod. I'm already bending the lame "JDBC" policy by using Spring JDBC, so I don't have the flexibility to use iBATIS.

For the moment, I've ended up doing a variation on #1 that seems cleaner: do a "shallow" population of FK domain objects (i.e. just the key value) in the RowMapper. Then I give the OrderDAO a reference to CustomerDAO using dependency injection, so it can fully populate the Customer object if it chooses. Not the ideal performance solution, but simplicity is key on this project...I am trying to train up some Java developers but stay within the organizational constraints.