Dec 7th, 2006, 09:02 AM
Spring best practices and guidelines
What are your best practices and guidelines with Spring? And why?
I want to start a discussion about Spring best practices and guidelines. A discussion where people can place their best practices and guidelines with an explanation why this best practice or guideline is good. Others can react on it with additional arguments why this is good, or with arguments why they disagree and maybe propose a better best practice or guideline.
My goal is: Get a list of all the Spring best practices and guidelines, including all their proís and conís.
I'll start the discussion by giving some best practices and guidelines.
Dec 7th, 2006, 09:04 AM
Always use auto-wiring. (Never ever use explicit wiring.)
Category: Spring core - configuration
Dec 7th, 2006, 09:05 AM
Bean idís must be in lowerCamelCase.
Category: Spring core - configuration
- All bean idís in the Spring documentation and samples are in lowerCamelCase.
Dec 7th, 2006, 09:06 AM
The reference manual has little snips which say, "the Spring team prefer to do it this way"....... I usually find them quite useful.
BTW, autowiring is voodoo and as such shouldn't be trusted
Check this out as well.
Last edited by karldmoore; Dec 7th, 2006 at 09:22 AM.
Reason: added link
Dec 7th, 2006, 09:12 AM
Donít place all your beans in one xml file
Donít place all your beans in one xml file (in large applications).
Split the configuration in different xml files. Minimal one xml file per architectural layer.
Category: Spring core Ė configuration
- Long xml files are hard to read.
Dec 7th, 2006, 09:14 AM
The default injection method to use is: setter injection
The default injection method to use is: setter injection.
Category: Spring core
- Almost all the code in the Spring sample applications use setter injection.
Last edited by Ward Bergmans; Dec 15th, 2006 at 03:23 AM.
Reason: There was a word missing in the title
Dec 7th, 2006, 09:28 AM
Every bean must have an id
Every bean must have an id.
Always use id to specify the default name of the bean.
If you need characters in your bean name that are not allowed in the id attribute, then you can provide additional names with the name attribute.
But always give the bean an id. Because if, in the future, someone wants use the bean with a name following the XML IDREF constraints (and wants to use the id), then that's possible.
Category: Spring core – configuration
- The id attribute can be validated by a xml parser, the name attribute can’t. And every good xml editor can validate on the id attribute. Because of the validation you will get less typo errors.
- To limit the risk of an accidental bean overwrite.
If no id or name attribute is specified, then Spring uses the bean’s class name as the name.
So if there are two beans of the same type without an id or name attribute specified, they will have the same name. (Note: this is an assumption, I still have to test this to be sure.)
In some situations one bean can overwrite the other if two beans have the same name.
Last edited by Ward Bergmans; Dec 21st, 2006 at 06:47 AM.
Dec 7th, 2006, 10:29 AM
Bean Name Space
It seems that all the beans in different context files share the same name space (i.e. if you have two beans with the same name, the last context.xml file that is loaded overwrites beans with the same name in previous ones).
Originally Posted by Ward Bergmans
Dec 7th, 2006, 11:16 AM
Indeed, useful when unit testing, pain when you can't understand why your code doesn't work.
Originally Posted by martinr
Dec 7th, 2006, 04:22 PM
Is there any best practice on how to use a hierarchy of bean factories?
I usually put data-source and transaction manager related beans(hibernateSessionFactory, dataSource, lobHandler) into a separate file so that I can replace it for different environments. The list of Hibernate mapping files I keep with the DAO's so that I can reuse it for the different environments.
Is there any beest practice on using aliases for switching between different environments?