Nov 2nd, 2006, 09:33 AM
And as well as just considering LOC arguments, you have to bear in mind that Spring configuration is not *code*. The Spring XML "language" is minimally complex and expressive, and very amenable to being processed by tools, unlike the equivalent Java. Even if the XML code were twice the bulk, you would have to consider that by taking particular definitions from a more expressive to a less expressive environment you have made a big gain.
Originally Posted by dejanp
And actually I think all things considered, modern Spring auto-proxying stuff &c will on balance actually *reduce* the size of complex applications - this becomes a constant cost that does not scale with the model size.
There is a fair "XML backlash" going on at the moment, with Javaites being panned for their lack of DSLs etc. by the declarative types. Bulky and unmanageable schemas such as BPEL, XMI etc. have also contributed to give XML configuration a bad name, but actually I believe Spring's use of XML is really pretty benign, even if it weren't helped along by increasingly great tools.
In case anyone had missed it, I should point out that SpringIDE is now really pretty stable and capable - http://springide.org/ - just a taste of what is coming down the tool chain.
Nov 2nd, 2006, 09:51 AM
IMHO, there is also the learning curve aspect in this "is it worth it" discussion. Once you get past the initial curve, it becomes relatively straightforward to add another business service bean to your spring config file.
Nov 2nd, 2006, 10:25 AM
Absolutely. One of my applications lost some 20% on size, just by porting to Spring 1.1 (and Spring 1.1 xml was really verbose).
Originally Posted by Bosmon
Nov 2nd, 2006, 10:27 AM
Sure, I will have a learning curve in any third party framework or tool. I really don't care about that. If it is worth, yes, I will pay the price of the learning curve.
The good thing that I hear about you is that everybody is happy using Spring and that talks very good about the framework.