I am developing a series of webservices (based on spring and spring mvc).

For the first time in my dev career I do plan on replacing the dao layer in the future(I have always seen it mentioned but never had to do it).

Currently I'm using spring annotations, so I could simply change the qualifier name of the injected dao in each place it is used; is there a better (global) mechanism I could use ?

Currently my code looks like this (declaring the dao) :

public class RegionDao implements IRegionDao

and Injecting it :

@Resource(name = "regionDao")
IRegionDao regionDao;

But going into each service class and changing the qualifier name seems rather long winded, is their a better way. Basically in the future I want to flip a switch and each reference to a regionDao will then point to newRegionDao and so on for other dao's.

A solution using annotations is preferred- for no other reason than I subjectively prefer them. But I realize this may be a case for xml based config ?

  • 2
    Are you sure it is worth your time now to implement something that (may or may not) be needed in the distant future? Commented May 9, 2012 at 8:43
  • 1
    @MartinWickman Sorry I don't understand what you are talking about ? We have a long term plan to change db structure/vendor. However we have a short term plan of providing additional functionality. Commented May 9, 2012 at 8:44
  • 1
    You said you want this because in the future, I want to.... This is often a case of yagni and overengineering, but your reasons might be valid. Just a heads up :) Commented May 9, 2012 at 8:48

2 Answers 2


You can add a layer of indirection by using property placeholders for class names:

< bean id="regionDao" class="${com.wibble.newRegionDao}" >

And then configuring DAOs class names in the property files.

I agree with other posters that this is possibly overkill to do this for a task you'll do as rarely as changing your persistence back end.

[This technique is possibly more useful in integration testing scenarios by the way - where you for instance want to run tests against one data store or messaging provider and run in production against another.]


  • +1 for a clever approach that I never considered before, however impractical.
    – maple_shaft
    Commented May 9, 2012 at 13:24
  • Why impractical? Ideal in our situation where we want to use different driver classes in different environments - say ActiveMQ in dev and MQ in production. Commented May 9, 2012 at 13:26
  • 1
    If you're running Spring 3.1+, they introduced Bean definition profiles where you can have bean configuration for multiple scenarios in one configuration file. If you're running in a web application, you can pass the active profiles as a servlet parameter. See blog.springsource.com/2011/02/11/… for an example. I'd personally prefer separate files, though.
    – ftr
    Commented May 9, 2012 at 13:42

Personally I fail to see what could be easier than changing the name of the Resource that I am injecting into my Service classes and integration tests. Even in a large system where you have hundreds of DAO's this will only take you what, 2 hours at most? And besides, you can just make an intern or fresher do it :)

For a truly one step process, I suggest configuring Spring through XML documents however. I know this isn't what you want to hear because I personally love Annotation based configuration as well, but considering that you anticipate a high likelihood of shifting data layers in the future then this could be a better idea for a number of reasons.

Also consider a system that you may need to deploy into very different configuration environments, possibly for different customers. Where I work we are a software vendor and our two major clients for one of our products both have different needs to host our software. One client has an enterprise license to Oracle, while the other has an enterprise license to SQL Server, neither of which want to spend additional money on database licenses and support for a single system, and rightfully so.

Creating a seperate Spring DAO configuration XML for each client at that point becomes a necessity for an automated build script that include the appropriate DAO configuration XML for the client build in question. So basically as clean as annotations may look and as easy as it makes deciphering the purpose and configuration of a class, annotations are essentially useless to me in this scenario.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.