Limiting Dependency on Spring Without Losing Power of Framework

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.

---

I've been married with the Spring Framework for a while and we use it extensively at my current work. One of the advantages of using Spring is that it was designed to be as less intrusive as possible, that is, you seldom have to implement some Spring specific interface, etc.

Unfortunately the best approach you can take, as far as I'm concerned, to minimize the dependency on spring classes due to the annotations use, is the use of XML configuration files, which also have its downside.

At the end of the day, as I see it, is that there is always a price to pay.