Injecting JdbcTemplate instead of just DataSource?

[ArtVandelay]

Hi all,

All the examples I have seen with regard to auto-wiring DAO classes have the DataSource being injected into the DAO instance via setter, and a JdbcTemplate created from the DataSource.

I was thinking about injecting the JdbcTemplate directly rather than using the DataSource to create one, but was wondering if there was some drawback to this that has not occurred to me. The only thing I can think of is that it might make the DAO slightly less generic, menaing if I were to switch from JdbcTemplate to needing a HibernateTemplate or back to raw JDBC, I would need to change the Spring config file along with the code.

No big deal, but it does save me a line of code when the JdbcTemplate is already there.

Thanks,

Art

[ojolly]

personally, I don't find bad the injection of a *Template bean. It indeed raise the level of abstraction from a DataSource.
As you mentionned, you have to change your config if you change the jdbc/hibernate/... way of doing. But you'd also have to change the DataSource if you were to store data in ldap instead of dbms. It is just a matter of abstraction level.

Olivier

[Rod Johnson]

I was thinking about injecting the JdbcTemplate directly rather than using the DataSource to create one, but was wondering if there was some drawback to this that has not occurred to me.

I don't think so. It's a matter of taste. One advantage of injecting the JdbcTemplate directly is that things like NativeJdbcExtractors and custom exception translators can be reused easily. I inject JdbcTemplate sometimes when I need such customization.

The only thing I can think of is that it might make the DAO slightly less generic, menaing if I were to switch from JdbcTemplate to needing a HibernateTemplate or back to raw JDBC, I would need to change the Spring config file along with the code

I don't think this is a significant issue. The change is still localized to one class and it's config. You wouldn't really want to go back to raw JDBC, would you :?:

Rgds
Rod

[ArtVandelay]

You wouldn't really want to go back to raw JDBC, would you

After using the JdbcTemplate and HibernateTemplate for a month or so now, I don't think I'll be going back to raw JDBC again. Just wanted to make sure I was not missing something with regard to injecting the Template.

As a side note, Spring this has made a tremendous impact on the testability of my DAO classes. It really is a significant benefit to be able to run these outside of any container. Thanks Rod and team for the contribution (the book is great by the way).

[rcui]

Recently, I am having a case where I have to disable the XML sql error mapping, I am extending StoredProcedure and try to manually inject JDBCTemplate, but it's not working properly. Here is what I did:
1. extend StoredProcedure, in the constructor, before compile(), create a new JDBCTemplate and set the SQLStateSQLExceptionTranslator, then set the new JDBCTemplate back.
2. When I run it, the ExceptionTranslator is reset back to the default one -SQLErrorCodeSQLExceptionTranslator(the jdbcTemplate field is my class, but the exceptionTranslator field is SQLErrorCodeSQLExceptionTranslator class, not SQLStateSQLExceptionTranslator).
However, if I just get the JDBCTemplate in the constructor and set the SQLStateSQLExceptionTranslator to it(before compile()), it works fine.

I also noticed in the class JdbcDaoSupport, there is a JDBCTemplate. This JDBCTemplate can be injected without problems. However, since most of the lowlevel db ops are sealed by StoredProcedure and other classes, this JDBCTemplate is seldomly used. I checked the petclinic example and found that the JDBCTemplate in the JdbcDaoSupport subclasses is used only once for the identity key, which is sealed by stored procedures in my case. So I created another DAO support class without the JDBCTemplate at all.

These are just my observation, I might miss/misunderstand something.

On the other hand, spring + ibatis works so smoothly.