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...)
Envoyé par
jyl2002
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...
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
1 |
0 |
