What’s the point of Spring XML configuration?
Don’t know about you but I always test, build, package, test, and deploy the entire app to release a change in config, so why is the Spring approach better than assembling my objects ourselves in code? Initialising our objects in XML is a popular option, so it must give us something.
One thing that Spring does not provide is Dependency Injection. Dependency Injection is a style of coding, and you don’t need a framework to code in a particular style. If you’re puzzled about how to do DI without Spring, take another look at the Gang-of-Four Abstract Factory and Builder patterns. Coding factories is no harder than writing XML, and even makes it easier to write chunkier Junit tests for assembled components.
What I think we get out of coding our factories using Spring XML is permission to relax the Java / OO rules during initialisation. At application initialisation we get to indulge in (lovely) dynamic typing, slightly more worrying global variables, and even the downright alarming excuse not to write tests for behaviour.
Dynamic typing
If there’s a type error it happens at runtime: its dynamic. And you’re still coding in a statically typed language because….. (*).
Global variables
The requirements change and your WidgetRepository, configured in the widget.xml, needs to get hold of a database connection to the “ooplah legacy system” configured in “ooplah.xml”. No problem – just pass in the “ooplahDataSource” bean id and you’re laughing. One of your Ooplah components needs a Widget, and the “widgetRepository” bean is ready and available. It’s all one big pot of bean soup.
Ok Spring does support hierarchical contexts, but know anyone making much use of them to partition their apps?
No need to test
So you’ve factored your code into small composable units? Well done. Your users will be delighted. And each unit is thoroughly unit tested? Excellent. (I bet you used Mock Objects, but I’ll let that go for now). Well the XML stuff is just config, so you don’t need to test that.
WRONG!
If you define behaviour by plugging your objects together in different ways then that configuration is code. No matter how well you’ve tested the individual object you need to test how they work together.
Even if you’ve automated end-to-end tests in place, you might ward away hours wasted at the debugger and fear of change by having some chunkier unit tests around your aggregate objects defining a particular behaviour.
A good side-effect of those chunkier tests is that they tend to encourage modular configuration with high adhesion within a single config file, and a few external dependencies stubbed for the test.
(*) .. because they’re paying me ;-)
![Contact email to pwjobs [[ at ]] merecomplexities.com](email.gif)
2 Comments:
Pretty much "me too", here.
I agree that Spring config is basically a way of reducing the amount of static typing tax you have to pay, which hints that one is in a halfway house and shouldn't be. Using thew right concrete tool for the right job is one thing, and maybe Spring XML is a better DSL for this stuff than doing the injection in code - but inconsistency at the high value/philosophy level as the trade off between static and dynamic typing is usually confusing and misguided, so yeah, pick a side.
(And globals and excuses not to test the whole system are not selling points, yes, yes.)
One little thing: you wrote "Don’t know about you but I always test, build, package, test, and deploy the entire app to release a change in config..."
The set of time critical embarassments/emergencies that are plausibly resolvable by updating the config on production hosts in order to shortcut the usual chain to deploy is small, but I have used one: updating a mistranslated string. However this is the only usecase I'm come across, and you clearly don't need anything as powerful as Spring config to enable it.
Hi Anthony,
About the "time critical embarassments" - Thanks for reminding me that contexts adnd environments vary.
In my recents experiences it has been as easy to do a complete build (or build on a branch) than release a single piece of config, and that was in my mind as I wrote.
Post a Comment
<< Home