Recently there has been a fundamental shift away from pure XML configuration, toward the use of Annotations where Spring is leading the charge. Spring is not alone, Hibernate also promotes the use of Annotations to describe persistable entities and their relationships. What results is a scattering of configuration markup throughout the code, and, as a result, domain objects, that now describe more than their atomic funtion - a mixing of concerns and so a violation of object oriented practices - namely the one that strongly suggests that an object only have one responsibility and therefore one reason to change (SRP). Further, this dilution of the XML DSL serves only to remove important concepts from the DSL, making it less complete and specific.
I'm not totally against annotations. I like the Annotations that replace marker interfaces - the ones used to mark key concepts like architectural layers - @Transaction, @Service, @Repository. In fact I prefer them to typical marker interfaces as they're extremely visible. The more visible a marker is, the better. Although, I'd prefer all marker annotations to come from the core java or jee libraries to reduce domain dependency on external frameworks. If this is not possible, roll your own.
Spring is by far the worst I've seen in this area. I recently wired an application together with a component-scan, a hibernate annotation aware bean and a transaction annotation aware bean - thats it!! That's crazy for all the wrong reasons. The config file isn't even a DSL anymore. It tells me nothing of what the application does or how it achieves it's purpose. It does tell me to trawl through the code, starting a base package, if I want details; Tim Veentjer blogs about similar experiences. What a bottom up approach! Advocates scream "It makes the Spring configuration clean". Actually its made the configuration irrelevant. Configuration is there to describe how your application achieves its purpose in some meaningful way that makes sense.
Actually its made the configuration irrelevant.
People who use the "It cleans up my application configuration" cry are really saying "I've pulled out too much detail in my configuration and often get confused with the correct level of abstraction." If you must pull everything out into the application configuration, put the noisy stuff that hides the intent of the application, in spring factories. If there is anything more than what you would use to describe your application in a five minute description - you have too much in there.
On that note, I use my application configuration file/s as a final refactoring aid to pin-point abstractions at the wrong level. Try it - you'll be amazed what you find - after you think you're done. Configuration DSL's are not something you use as a proverbial carpet to sweep crap under.
Jumping down to the code, the classes, particularly in the persistence layer become less readable; overly cluttered with perssistable annotations like @Table, @Column, @Id, @Constraint etc. What ever happend to domain objects not knowing anything about the environment beyond their immediate domain? Out of process markup is surely too much for a humble domain object to know about.
