Je pense que t'as pas compris grand chose au concept vu ce que t'en dis.
Comme j'ai demande plus haut ,je vois pas comme la DI peut etre integree dans le langage, vu que le concept meme du truc, c'est en gros:
Une classe se base sur certains objets (dont l'implementation peut etre remplacee) pour faire ses operations.
L'exemple de base, c'est un service qui a un besoin d'un DAO pour recuperer ses objets depuis la db et ensuite en faire ce qu'elle a faire.
Demander au service d'instancier en dur sa dependance, ie le DAO ici, ca pose de gros problemes.
Le premier evident etant que si ton DAO est thread safe, ce qu'on espere tous, c'est plutot idiot et meme dangereux d'en instancier plusieurs.
Conceptuellement, ton service n'a pas a savoir comment ton dao est architecture, il ne possede pas le dao, se contente de l'utiliser. Un autre qu'il possede encore moins, c'est la config du dao (host db, login pass et ce genre de conneries).
Et la pour le coup, la derniere chose que tu veux faire, c'est que ton service ai a connaitre tout ca.
Ca va te donner, dans le constructeur du service:
monDao = MonDAOORacle(hots, login, pass);
et si tu passes a pgsql, faut que tu passes dans tous tes services et que tu changes par
monDao = MonDAOPGsql(host, login, pass);
C'est ballot quand meme...
C'est encore plus idiot de demander a ton dao d'instancier les services, ca le lie a un composant qui lui est totalement etranger. Son boulot, c'est de cracher des objets depuis la db, et de les y remettre, c'est tout.
Bref, le probleme est donc: comment faire pour que les dependances du service soient satisfaites?
Le service ne peut pas creer le dao, mais le dao ne peut pas creer le service.
Ben la solution c'est que ces objets n'ont pas a gerer leur dependances puisqu'ils n'ont pas, et n'ont pas a avoir, l'information necessaire. Par contre, une classe externe, dont le but est de gerer tout ce merdier, elle a l'information et le contexte elle, et peut donc coordoner tout ce bordel.
Ton dao est un singleton? Tres bien, spring va t'en creer une seule instance et la donner a tout le monde.
FInalemet singleton, c'etait pas une bonne idee et tu refactores le DAO?
Pourquoi le service devrait connaitre les details d'implem du DAO? Il se contente d'appeler des methode publiques dessus.
Pas grave, tu changes un attribut dans la config de spring, et chaque service aura son instance a lui.
Le client a un sursaut de decence, et il passe la db d'oracle a PGSql?
Pourquoi le service devrait savoir quelle db stocke le tout? il travaille avec des objets lui, pas des relation!
Ben tu changes l'implem de ton dao dans spring et ca roule.
Tu fais des tests unitaires et ton DAO est en fait un simple mockup? Pourquoi est ce que le service devrait avoir connaissance de l'existence meme de tests unitaires?
Allez hop, tu changes l'implem de ton bean dans spring et paf, ton service n'est meme pas au courant qu'il parle a un dao bidon.
Et sans toucher la moindre ligne de code.
Ton service a besoin d'un DAO et il se fout eperdumment de savoir d'ou il vient. Et tant mieux, peut importe d'ou tu viens, dis moi plutot ou tu va.
L'archi du dao ne fuit pas dans le service, celle du service ne fuit pas dans le dao, tout le monde est isole et ton appli est plus simple a maintenir, modifier et a developper.
Ca t'eclaire un peu plus sur le DI et l'IoC en general?
Apres, spring, ca se limite pas qu'a ca non plus, mais ca reste un de ses usages premiers.
[^] # Re: Rien de transcendant dirait-on
Posté par thedude . En réponse au journal Noop : encore un nouveau langage ou bien nouvelle génération de langage. Évalué à 2.
Je pense que t'as pas compris grand chose au concept vu ce que t'en dis.
Comme j'ai demande plus haut ,je vois pas comme la DI peut etre integree dans le langage, vu que le concept meme du truc, c'est en gros:
Une classe se base sur certains objets (dont l'implementation peut etre remplacee) pour faire ses operations.
L'exemple de base, c'est un service qui a un besoin d'un DAO pour recuperer ses objets depuis la db et ensuite en faire ce qu'elle a faire.
Demander au service d'instancier en dur sa dependance, ie le DAO ici, ca pose de gros problemes.
Le premier evident etant que si ton DAO est thread safe, ce qu'on espere tous, c'est plutot idiot et meme dangereux d'en instancier plusieurs.
Conceptuellement, ton service n'a pas a savoir comment ton dao est architecture, il ne possede pas le dao, se contente de l'utiliser. Un autre qu'il possede encore moins, c'est la config du dao (host db, login pass et ce genre de conneries).
Et la pour le coup, la derniere chose que tu veux faire, c'est que ton service ai a connaitre tout ca.
Ca va te donner, dans le constructeur du service:
monDao = MonDAOORacle(hots, login, pass);
et si tu passes a pgsql, faut que tu passes dans tous tes services et que tu changes par
monDao = MonDAOPGsql(host, login, pass);
C'est ballot quand meme...
C'est encore plus idiot de demander a ton dao d'instancier les services, ca le lie a un composant qui lui est totalement etranger. Son boulot, c'est de cracher des objets depuis la db, et de les y remettre, c'est tout.
Bref, le probleme est donc: comment faire pour que les dependances du service soient satisfaites?
Le service ne peut pas creer le dao, mais le dao ne peut pas creer le service.
Ben la solution c'est que ces objets n'ont pas a gerer leur dependances puisqu'ils n'ont pas, et n'ont pas a avoir, l'information necessaire. Par contre, une classe externe, dont le but est de gerer tout ce merdier, elle a l'information et le contexte elle, et peut donc coordoner tout ce bordel.
Ton dao est un singleton? Tres bien, spring va t'en creer une seule instance et la donner a tout le monde.
FInalemet singleton, c'etait pas une bonne idee et tu refactores le DAO?
Pourquoi le service devrait connaitre les details d'implem du DAO? Il se contente d'appeler des methode publiques dessus.
Pas grave, tu changes un attribut dans la config de spring, et chaque service aura son instance a lui.
Le client a un sursaut de decence, et il passe la db d'oracle a PGSql?
Pourquoi le service devrait savoir quelle db stocke le tout? il travaille avec des objets lui, pas des relation!
Ben tu changes l'implem de ton dao dans spring et ca roule.
Tu fais des tests unitaires et ton DAO est en fait un simple mockup? Pourquoi est ce que le service devrait avoir connaissance de l'existence meme de tests unitaires?
Allez hop, tu changes l'implem de ton bean dans spring et paf, ton service n'est meme pas au courant qu'il parle a un dao bidon.
Et sans toucher la moindre ligne de code.
Ton service a besoin d'un DAO et il se fout eperdumment de savoir d'ou il vient. Et tant mieux, peut importe d'ou tu viens, dis moi plutot ou tu va.
L'archi du dao ne fuit pas dans le service, celle du service ne fuit pas dans le dao, tout le monde est isole et ton appli est plus simple a maintenir, modifier et a developper.
Ca t'eclaire un peu plus sur le DI et l'IoC en general?
Apres, spring, ca se limite pas qu'a ca non plus, mais ca reste un de ses usages premiers.