Simplified Architecture of Web Projects
WAR
- spring dependency injection (most use XML)
JAR
- DAO
- Domain
The Problem:
With Spring 3 and 2.5+ annotations building Repositories and services has become much easier to wire together. However, because often a @Service conceptually belongs in the JAR far more than the WAR, and certainly auto-wired Repositories, and transactional classes, do. How do people work where it’s expected to not have “spring dependencies” in the actual JAR classes, which I’ve found in multiple companies is a goal.
Obviously I know you cannot remove ALL spring dependencies if you want to use Annotations and Transactions, since they are actually spring classes, but is there some best practice people use that limit the liability if there are changes to spring, or there are projects that use OLDER spring versions in their WAR than what is included in the JAR?
I’m assuming this must be a common problem, but if not, please ask and I will elaborate
Annotation based dependency injection is essentially a (very convenient) violation of Separation of Concerns. The dependency you describe is the result of this. If you would like to avoid it you should do your wiring in a separate package (i.e. not use annotations for dependency injection).
It is possible however to wire based on your own custom annotations. Depending on how far you are willing to go this can improve things to leave only a single spring dependency (your extending annotation) or remove the dependencies altogether. This still violates SoC, but with much less dependency on Spring.
Usually I find that either living with the downsides of annotations, or completely living without them (using Java Config or plain old XML) are the most maintainable options. Custom annotations are another maintenance burden.