Spring best practices and guidelines

[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

[jstehler]

Use constructor injection for properties that must be set in a certain order.

Only provide (a) constructor(s) that guarantee(s) that the properties are set in the required order.

Category: Spring core

Argumentation:

• If properties must be set in a certain order, you would normally design you class like this: the class will only have constructors that make sure the properties are set in the right order.
  Why would you change that design when you use the Spring framework???
  The whole idea behind Spring is that you can design your classes how you like and have Spring work for you, not the other way around.

Even if you have this requirement of setting properties in a specific order, why not defer the logic which processes the values to an init method, invoked after the object has been constructed / injected? I prefer using setters over constructor args, as it leads to far more legible configuration files (you cant specify constructor args by name). Using the init method approach allows a greater degree of flexibility for clients to configure an object before its use, and you can (and should) use assertions in that method to ensure that required properties have been set (there is also an annotation-based approach for required-ness in the lastest couple versions of Spring, I believe). And you dont have to tie yourself to Spring by implementing InitializingBean, since you can explicitly name the method to invoke post-injection.

What I usually do to ease unit testing is to create both a default constructor and one which takes all of my required properties; the latter invokes the init method after setting the values. This leads to APIs which are accessible within and without the Spring context.

One argument for constructor injection I suppose would be in the case of immutable objects, but if clients code to interfaces instead of implementations, the setters are hidden anyways.

[Jörg Heinicke]

One argument for constructor injection I suppose would be in the case of immutable objects, but if clients code to interfaces instead of implementations, the setters are hidden anyways.

The immutable object argument is not that much about somebody changing the object unexpectedly but about clearness in regard to potential states of the object.

Joerg