Spring best practices and guidelines

[Ward Bergmans]

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.

[Ward Bergmans]

Category: Spring core - configuration
Argumentation:

• It saves typing.

[karldmoore]

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.
http://www.onjava.com/pub/a/onjava/2...practices.html

[Zinno1973]

Category: Spring core - configuration
Argumentation:

• It saves typing.

I would not recommend using auto wiring in large projects. The chances of unexpected behavior increases and it makes the xml files more difficult to read/understand.

[karldmoore]

Useful one.

Specifying the target bean by using the local attribute leverages the ability of the XML parser to validate XML id references within the same file. The value of the local attribute must be the same as the id attribute of the target bean. The XML parser will issue an error if no matching element is found in the same file. As such, using the local variant is the best choice (in order to know about errors are early as possible) if the target bean is in the same XML file.

[TheStijn]

Specifying the target bean by using the local attribute leverages the ability of the XML parser to validate XML id references within the same file. The value of the local attribute must be the same as the id attribute of the target bean. The XML parser will issue an error if no matching element is found in the same file. As such, using the local variant is the best choice (in order to know about errors are early as possible) if the target bean is in the same XML file.

I do not really get why this is advised.
I see 2 disadvantages of working with the local attribute:
1. increases clutter since there is no shortcut form for the ref local;

 
<property name="prop" ref="someBean />

would have to be rewritten as:

<property name="prop">
<ref local="someBean"/>
</property>

2. when the decision is made to split up 1 xml config file into 2 or more then it's possible that a lot of these local refs will have to be rewritten as 'normal' ref's.

At least, that is my opinion.

greetz,
Stijn

[Jörg Heinicke]

2. when the decision is made to split up 1 xml config file into 2 or more then it's possible that a lot of these local refs will have to be rewritten as 'normal' ref's.

That's exactly the reason why I don't use it. I like to refactor and move stuff around ...

Joerg

[Draw]

Always use auto-wiring.

My best practice is the opposite:
Always use explicit wiring.

Argumentation:

• Application works as configured. It does nothing more than you’ve configured and nothing less. You can see how it is configured (nothing magical happens.)
• Auto-wiring is less self-documenting than explicit wiring.
• With auto-wiring by name the renaming of bean or property names easier leads to errors than with the use of explicit wiring.
• Auto-wiring by name may lead to artificial property names. (So that you can take advantage of the auto-wiring functionality.)
• With auto-wiring by type you can only have one bean of a certain type in your configuration. For example, if there are two DataSources, auto-wiring by type will not work.

[karldmoore]

Personally, I don't use it. I agree with a lot of your points. The few times I have used it, people really didn't like it. They wanted to know where the beans were coming from. As I said previously, I'm glad its there, but it is voodoo.

[debasishg]

My best practice is the opposite:
Always use explicit wiring.

Argumentation:

• Application works as configured. It does nothing more than you’ve configured and nothing less. You can see how it is configured (nothing magical happens.)
• Auto-wiring is less self-documenting than explicit wiring.
• With auto-wiring by name the renaming of bean or property names easier leads to errors than with the use of explicit wiring.
• Auto-wiring by name may lead to artificial property names. (So that you can take advantage of the auto-wiring functionality.)
• With auto-wiring by type you can only have one bean of a certain type in your configuration. For example, if there are two DataSources, auto-wiring by type will not work.

+1 on your auto-wiring thoughts. I have also generally observed clients do not like the terseness of auto-wiring. I support your call for using explicit wiring.

- Debasish