Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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) :

@Repository("regionDao")
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 ?

share|improve this question
2  
Are you sure it is worth your time now to implement something that (may or may not) be needed in the distant future? –  Martin Wickman May 9 '12 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. –  NimChimpsky May 9 '12 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 :) –  Martin Wickman May 9 '12 at 8:48
add comment

2 Answers

up vote 3 down vote accepted

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.]

http://static.springsource.org/spring/docs/1.1.5/api/org/springframework/beans/factory/config/PropertyPlaceholderConfigurer.html

share|improve this answer
    
+1 for a clever approach that I never considered before, however impractical. –  maple_shaft May 9 '12 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. –  Benjamin Wootton May 9 '12 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 May 9 '12 at 13:42
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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