Bonjour à tous,

Je suis sur un projet dans lequel j'ai 300 services DAO pour un controller. Je voudrais éviter de faire 300 Autowired...

J'ai déjà testé d'injecter l'ApplicationContext via l'interface ApplicationContextAware. Cela me retourne le bon bean mais les annotations custom s'y trouvant ne sont pas lues par l'API Reflect.

PS: Je précise que tout fonctionne correctement avec Autowired

Voila, si quelqu'un a une idée ! j'suis preneur !

(Spring 3.1)

Bonjour.

Quelle annotation custom ?

Tu stockes l'ApplicationContext dans un champ statique, initialisé au démarrage via une classe annotée de ApplicationContextAware ?
Pourquoi ne pas directement injecter l'ApplicationContext dans ton service ?

Faire des applicationContext.getBean() sur des beans singletons n'est pas propre : les @Autowired sont là pour ça !

Si tu trouves que tu as trop d'@Autowired cela signifie que ton service fait trop de chose : il faut le découper en sous-service.
Tu peux les appeler Repository ou Manager, comme tu veux. 

Merci de ta réponse

Quelle annotation custom ? -> une annotation fait maison

import java.lang.annotation.Documented;
import java.lang.annotation.ElementType;
import java.lang.annotation.Inherited;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
public @interface OGCValidator {
       String[] validators() default {};
}

Tu stockes l'ApplicationContext dans un champ statique, initialisé au démarrage via une classe annotée de ApplicationContextAware ?

-> j'ai testé plusieurs méthode:

• faire un autoWired de ApplicationContex
• implémenter l'interface ApplicationContextAware pour définir une variable static dans mon controller

Pourquoi ne pas directement injecter l'ApplicationContext dans ton service ? -> C'était mon premier choix mais vue que ça ne fonctionnait pas, j'ai supprimer les intermédiaires pour diagnostiquer le problème. Le but final est d'avoir :

• le controller de façade qui interprète les requêtes et crée les réponses
• le service générique qui sert principalement de routeur vers les services DAO
• les 300 services  DAO

Faire des applicationContext.getBean() sur des beans singletons n'est pas propre : les @Autowired sont là pour ça ! -> Je suis d'accord mais dans la situation actuelle, je trouve les 300 autowired encore moins conseillés

Si tu trouves que tu as trop d'@Autowired cela signifie que ton service fait trop de chose : il faut le découper en sous-service.
Tu peux les appeler Repository ou Manager, comme tu veux. -> S'il n'y avait que moi, je referais toute l'application mais contrainte du projet, interdiction de toucher aux services DAO (sous la responsabilité d'une autre personne). Je propose une solution pour remplacer ses 300 controllers qui faisait tous les mêmes actions au détails de changer d'entité.

Merci de m'aider

Ukusan

ukusan a écrit:

Faire des applicationContext.getBean() sur des beans singletons n'est pas propre : les @Autowired sont là pour ça !
-> Je suis d'accord mais dans la situation actuelle, je trouve les 300 autowired encore moins conseillés

Avec ou sans attribut, le problème sera toujours le même : ton service manipule trop de DAO.
Ces liens de dépendances peuvent être fait en diagramme de classe UML : que tu "représentes" le lien de dépendance par un attribut ou une "instanciation" dans la méthode, le lien sera toujours présent.
Remplacer les attributs par des applicationContext.getBean() ne fera que cacher la poussière sous le tapis, rendant en plus de cela plus difficile la maintenance (car ce n'est pas la bonne pratique).

ukusan a écrit:

Si tu trouves que tu as trop d'@Autowired cela signifie que ton service fait trop de chose : il faut le découper en sous-service.
Tu peux les appeler Repository ou Manager, comme tu veux.
-> S'il n'y avait que moi, je referais toute l'application mais contrainte du projet, interdiction de toucher aux services DAO (sous la responsabilité d'une autre personne). Je propose une solution pour remplacer ses 300 controllers qui faisait tous les mêmes actions au détails de changer d'entité.

Je comprends la contrainte, l'ayant (trop) souvent subie 
Cependant, quitte à vouloir faire propre, autant le faire réellement. Ici le nombre d'attribut n'est pas le problème mais la conséquence : le problème c'est de tout avoir centralisé dans le même service.

L'idée est en fait d'avoir une sorte de web service CRUD enrichi. J'ai la structure suivante:

Donc mon service ne possède pas tant de fonction que ça (15 au total) mais il agit quand même sur les 300 DAO que je voudrais lui injecter sur demande

Sur tes conseils, quitte à faire moche autant que ça soit fonctionnel. Je tente les 300 attributs

PS: j'ai testé de faire un Autowired de list hier

List<GenericService<?>> services;
	
	@Autowired
    public void setServices(List<GenericService<?>> services){
        this.services = services;
    }

...peu concluant

-
Edité par ukusan 6 décembre 2016 à 9:56:17