The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Spring/Inversion of Control/Dependency Injection...

Have any of you guys used Spring or another framework based on it's fundamental concepts (i.e., dependency  injection)? 

If so, could you share your experiences with this and if you found it easier than previously used alternatives?
Crimson Send private email
Wednesday, April 05, 2006
Yep, we're using it to great success.  (Well, so far -- we haven't shipped yet..) I think the biggest benefit is that setup is in the application context and is shared by the real app and the unit tests.  As people add the new dependancies and config optoins to the "eal app, the unit and integration tests are automatically kept up to date!  (Now if we could just get people to run the unit tests!)

Also because Spring controls when transactions get committed,  in an integration test environment you can configure Spring to roll back the transaction at the end of the test. This keeps the database in a known state so the integration tests can be run in any order.
Steve S
Thursday, April 06, 2006
I've used Spring with the Hibernate - Spring Integration, and it forces you to do a clean seperation of DAO Objects from Logic Beans. Also leads to cleaner code, and as the previous poster memtioned, transaction rollback in your unit tests, so you have a db with known state.
The only issue I had was with editing the XML config files, it's really hard to find mistakes if you mispelled, or something, but isn't that true for all J2EE environments some with massive amount of XML config files
SR Send private email
Thursday, April 06, 2006
Thanks guys.

The integrated transaction support and being able to switch in tests on the real app seems to be where the biggest productivity gains come from.

Are there any big headaches you have to deal with that you didn't have to deal with before?  I'm guessing the XML file stuff mentioned by SR would probably be near the top of that list.
Crimson Send private email
Thursday, April 06, 2006
I've found that if you're doing iterative development, make a change, run the unit tests, repeat, that its pretty easy to know when you've broken the app context.

If I hacked that app context all day before trying to run it, then yeah, it would be a pain to figure out where it broke.

We're not using the new 2.0 version yet (its still a release candaidate I think...) but they made the XML much simpler.
Steve S
Friday, April 07, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz