@Olivier : L’autre possibilité prise en charge par Spring est d’utiliser l’annotation @Qualifier qui permet de donner un qualificatif à une classe et de différencier deux classes en cas de conflit. Dans votre exemple, vous auriez pu ajouter un @Qualifier(value= »userManagement ») et @Qualifier(value= »wareHousing ») par exemple.

Merci pour vos encouragements !
Manuel@Xebia

Pour l’injection de dépendance, j’utilise quasi exclusivement l’annotation standard @Resource qui permet en fait de faire aussi bien de l’injection par type que par nom. La règle semble être la suivante:
* Si le nom de bean peut être résolu, il est utilisé.
* Sinon un lookup par type est fait et, si une instance unique du type voulu existe, elle est injectée.

Le nom du bean est résolu au choix:
* Avec la valeur de l’attribut name de l’annotation @Resource.
* Avec le nom du champs ou de la propriété JavaBean décorée par l’annotation.

Quant au nom d’un bean déclaré à l’aide d’une annotation @Repository/@Controller/@Component/@Service, il est égal:
* A la valeur de l’attribut value de l’annotation si elle est renseignée.
* Au nom simple de la classe avec la première lettre en casse réduite.

Ainsi, on pourra

// Defaults to « fooAction » bean name
@Component
public class FooAction implements Action {
…
}

@Component(« notFooAction »)
public class BarAction implements Action {
…
}

@Component
public class MyUniqueActionBar {

// Resolves injection from the field name
@Resource
private Action fooAction;

// Resolves injection from the annotation attribute value
// We inject the same instance here!
@Resource(« fooAction »)
private Action anotherFooAction

// Inject from the attribute value
@Resource(« notFooAction »)
private Action anotherBarAction;

// WARNING!! This last injection will NOT work
// No bean name matches
// And no unique instance of type Action exists
@Resource
private Action barAction;

}

public class MyFrame extends JFrame {

// Will work if we assume there is only one bean of type MyUniqueActionBar
@Resource
private MyUniqueActionBar actionBar

}

Pour avoir réalisé des portions de code amenées à changer très fréquemment, cette méthode réduit énormément le nombre de lignes pour déclarer et injecter nos beans. Cela est particulièrement utile en prototypage.

Si la base de code devient particulièrement importante et que des beans déclarés par annotations portent le même nom simple de classe (rendant inutile la génération de nom automatique), il peut être intéressant d’utiliser des constantes pour expliciter le nom des beans (cette solution a ses propres inconvénients en termes de découplage).

Ainsi:

package warehousing;
public interface FooService {

String BEAN_NAME = « warehousing.fooService »;

}

package usermanagement;
public interface FooService {

String BEAN_NAME = « userManagement.fooService »;

..
}

@Service(usermanagement.MyService.BEAN_NAME)
public class MyFooService implements usermanagement.FooService {

..

}

@Controller
public class MyController {

@Resource(name=usermanagement.FooService.BEAN_NAME)
private usermanagement.FooService usermanagementFooService;

@Resource(name=warehousing.FooService.BEAN_NAME)
private warehousing.FooService warehousingFooService;

}

Merci à Xebia pour cet article!

Excellent article, comme toujours chez Xebia

Pour répondre à Philippe, il est toujours possible de configurer aspectj ou Hibernate en utilisant une configuration XML.
Pour aspectj, en particulier, cela peut-être plus simple d’utiliser des annotations, mais il est vrai que cela « pollue » un peu de le code, comme vous dites.

En fait, nous proposons les deux options (XML ou annotations), et même de faire un mix des deux suivant vos besoins. Ceci dit, nous proposons un framework générique avec de nombreuses options, à vous de voir ce qui est le mieux pour votre projet.

C’est à ce niveau que toute l’expertise d’une société telle que Xebia (par ailleurs partenaire SpringSource) peut vous aider : nous fournissons les outils, ils vous aident à les utiliser au mieux.

Cordialement,

Julien Dubois.

Je trouve votre article très instructif. Toutefois, je suis plutôt allergique aux annotations en règle générale à cause de l’obscurcissement du code induit.
Dans votre dernier paragraphe vous indiquer que l’AOP ou JPA « peuvent » rester dans le fichier XML. Pourquoi ?
Selon moi, les annotations n’améliorent pas la lisibilité du code, surtout lorsqu’on passe tous les frameworks (et ils sont nombreux au sein d’un projet : W-S, ORM, MVC, AOP, etc.) en annotations. De plus, la configuration d’un framework gagne à ne pas être éparpiller dans le code, mais centralisée dans un fichier de configuration, non ?
De plus, lorsque je vois des beans contenant des infos relevant de problématiques techniques transversales et non métier, je me dis qu’on retourne dans la philosophie EJB de pollution du code.

Que pensez-vous plus généralement des annotations, dans quelle(s) situation(s) pensez-vous qu’elles apportent une réelle valeur ajoutée ?

Excellent blog BTW, continuez comme ça

http://blog.developpez.com/djo-mos?title=de_la_di_avec_spring_2_5_sans_xml_java_s#more5346

Bon, c’est pas très orthodoxe, et on se rapproche de Guice, mais c’est juste un proof of concept

Cordialement.