Discussion :

[Philippe Vialatte]

Cette discussion est consacrée à l'article intitulé "Injection de dépendances en .NET, pattern, intérêt et outils"

Dans cet article, on va voir ce qu'est l'injection de dépendances, son intérêt, et les outils permettant de la mettre en œuvre.

Vous pouvez y poster vos commentaires concernant l'article.

L'article se trouve à l'adresses suivante :
http://philippe.developpez.com/artic...dedependances/

[tomlev]

Très intéressant tout ça, ça me donne des idées pour la nouvelle archi de l'appli que je développe au boulot

Petite question : j'entends pas mal parler de Castle Windsor, mais je ne le vois pas dans ta liste de containers IoC. Tu l'as déjà utilisé ? Qu'est-ce qu'il vaut par rapport aux autres ?

[Philippe Vialatte]

Petite question : j'entends pas mal parler de Castle Windsor, mais je ne le vois pas dans ta liste de containers IoC. Tu l'as déjà utilisé ? Qu'est-ce qu'il vaut par rapport aux autres ?

Alors, j'en ai effectivement entendu parler, mais je ne m'en suis jamais servi...
Tu trouveras plus d'infos ici :
http://msdn.microsoft.com/en-us/library/aa973811.aspx

Il y'a aussi AutoFac, et deux ou trois autres frameworks que je n'ai pas inclus dans la liste.

Personnellement, je reste convaincu par StructureMap, mais si il faut switcher, j'irais probablement voir du coté d'AutoFac -> http://code.google.com/p/autofac/

Dans l'ensemble, je préfère initialiser tout dans le code, avec des interfaces fluides ou des lambdas

[nico-pyright(c)]

C'est dommage que les déclarations xml ne soient pas les plus simples.
C'est dommage d'avoir à recompiler si le besoin se fait d'avoir à changer l'implémentation résolue après une livraison.
Sinon, article intéressant

[Philippe Vialatte]

C'est dommage que les déclarations xml ne soient pas les plus simples.
C'est dommage d'avoir à recompiler si le besoin se fait d'avoir à changer l'implémentation résolue après une livraison.

C'est clair...c'est pour cela que je prefere structuremap, c'est encore le plus light a configurer en XML...

Sinon, article intéressant

Merci

[Arthis]

Merci Philippe pour ces deux articles (SOLID et celui ci).

Lecture très intéressante... Malheureusement, ces concepts ne font pas toujours l'unanimité dans la "vraie vie", a cause des collègues ou encore de la nature même des développements.

Je travaille actuellement dans une agence web qui ne fait que des sites webs promotionnels, donc à durée de vie très courte (2-3 mois généralement). C'est du site web jetable. Je leur ai présente un site web modèle avec séparation en couche service, model, donnée, des interfaces, et injection de dépendance par le constructeur.

Résultat, il ont tout rejeté arguant qu'ils ne veulent pas modifier le code à 30 endroits quand ils veulent ajouter une fonction que le client veut à la dernière minute.

N'y a t'il pas à ton avis une certaine masse critique qui justifierait l'emploi de ces façons de faire? Cela serait intéressant de mettre des chiffres la dessus d'ailleurs.. je ne sais pas si de la littérature existe à ce sujet..

[Maniak]

Cette discussion est consacrée à l'article intitulé "Injection de dépendances en .NET, pattern, intérêt et outils"

Juste un petit pinaillage, histoire de mériter le pseudo :)

L'acronyme indiqué pour l'inversion de dépendance (le principe) est DI, alors que c'est l'acronyme de Dependency Injection (le pattern). Le principe d'inversion de dépendance, c'est DIP.

Mis à part ça rien à redire, je vais jeter un oeil sur StructureMap du coup :)

[Philippe Vialatte]

L'acronyme indiqué pour l'inversion de dépendance (le principe) est DI, alors que c'est l'acronyme de Dependency Injection (le pattern). Le principe d'inversion de dépendance, c'est DIP.

Pas faux

Faut que je note de el modifier, tiens

Sinon, c'est marrant, dans la foulee du message dÁrthis, voir les posts suivants :
http://www.joelonsoftware.com/items/2009/09/23.html
http://blog.objectmentor.com/article...ape-programmer
http://jeffreypalermo.com/blog/debun...pe-programmer/
http://www.rgoarchitects.com/nblog/2...rogrammer.aspx

[mastervanou]

Merci pour l'article.
C'est une technique que j'utilise depuis longtemps dans mes dev, mais n'étant pas très portée sur la théorie j'en ignorais le nom...
J'ai utilisé cette façon de faire car c'est venu tout seul et en plus ca m'évite la redondance de code.
En tout cas merci pour les infos

[jyl2002]

Bonjour,

7 ans plus tard, j'imagine que cet article est encore en forte visibilité des développeurs de passage, qui se basent probablement dessus pour faire le choix de leur conteneur IoC.
Mais aujourd'hui, est-il toujours valable ? Comment ont évolué ces conteneurs ? Certains ont-ils disparu ? Ou au contraire gagné en maturité ?

Par exemple faut-il toujours, avec Spring.Net, utiliser à la fois un cast et une magic string pour accéder à une instance ? (ce que je trouve aberrant, ça ne passerait jamais les revues de code chez nous !).
Bref, ce serait super si quelqu'un pouvait actualiser cet article. Si vous avez aussi des retours d'expérience sur l'un et l'autre ce serait aussi super de les poster ici (à noter : pour moi juste dire "ça marche bien chez nous" c'est pas vraiment un retour d'expérience hein !).

Au plaisir de vous lire...

PS : Personnellement j'ai toujours eu du mal à comprendre l’intérêt de ces conteneurs : ça fait longtemps qu'on fait de l'injection de dépendances chez nous, et on n'a pas utilisé pour autant un composant externe. Alors quand un auditeur écrit noir sur blanc dans son rapport "il n'y pas de technique d'IOC sur le projet étant donné qu'il n'y a aucune référence à Ninject ou Spring.Net", et qu'il rajoute un lien vers l'article de developpez.com, on se dit juste qu'il n'a rien compris ! Et en plus après il faut aller expliquer à votre DG que l'auditeur est un boulet...

[Maniak]

Ah tiens, ça faisait longtemps que je n'étais plus passé. Apparemment j'étais abonné à ce topic :)

De mon côté... 6 ans et demi après donc, je suis toujours avec StructureMap. Ça gère très bien le peu que je lui demande, à savoir regrouper au même endroit la config des diverses dépendances. Dans le cas d'ASP.NET MVC, entre l'intégration à la pipeline pour créer les contrôleurs (et donc tout le reste) et les "sous-containers" correspondant aux requêtes (et qui appellent Dispose proprement si nécessaire ensuite), ça me va.

Et forcément, ni cast ni magic string, tout au plus un GetService<T> pour les rares cas où il y a besoin d'y accéder directement (notamment les action filters qui ne sont pas créés via le dependency resolver normal parce que ce serait trop simple sinon...)

PS : Personnellement j'ai toujours eu du mal à comprendre l’intérêt de ces conteneurs : ça fait longtemps qu'on fait de l'injection de dépendances chez nous, et on n'a pas utilisé pour autant un composant externe. Alors quand un auditeur écrit noir sur blanc dans son rapport "il n'y pas de technique d'IOC sur le projet étant donné qu'il n'y a aucune référence à Ninject ou Spring.Net", et qu'il rajoute un lien vers l'article de developpez.com, on se dit juste qu'il n'a rien compris ! Et en plus après il faut aller expliquer à votre DG que l'auditeur est un boulet... :weird:

Been there done that :)

Dans mon cas donc, l'intérêt est une bête histoire de facilité pour le paramétrage. Pas la peine de s'embêter à recoder le nécessaire quand il y a déjà une petite librairie dispo qui le fait très bien, intégrée au framework et qui ne ramène pas 50 packages NuGet inutiles. Et le fait que je tourne essentiellement sur ASP.NET y est pour beaucoup vu qu'il y a du coup à gérer les dépendances au niveau application et au niveau de chaque requête (e.g. sessionfactory NHibernate pour l'appli, session/transaction NHibernate pour chaque requête). Aucun accès à StructureMap ailleurs que dans la config initiale.

Pour une appli 'normale', à moins d'avoir vraiment bcp d'instances à injecter avec des cycles de vie différents et/ou des conditions particulières pour créer les instances, l'intérêt se réduit d'un grand coup.

Au final, l'important est l'injection de dépendances. Que ce soit fait à la main ou via une librairie, c'est juste un détail d'implémentation. Si une librairie peut simplifier la vie dans le cas du projet en question, zog zog. S'il n'y en a pas besoin, encore mieux, ça fait toujours un package de moins.

Et l'important de juste après est surtout de ne pas utiliser ces librairies en tant que service locator, en les appelant directement à plein d'endroits pour récupérer des instances de tout et n'importe quoi. Là ce n'est plus de l'injection de dépendances mais ça devient très similaire à de l'utilisation de variables globales. Et on sait ce que ça vaut :)