J'ai passé au moins quelques semaines dans la même situation que vous êtes: lire toujours qu'IOC était certainement le chemin à parcourir, mais pas tout à fait attraper la « vision » encore. J'ai continué à lire et à relire des articles sur le sujet jusqu'à ce que je sois un peu à l'aise, puis j'ai commencé à réécrire certaines parties de notre code pour utiliser DI. Comme je l'ai fait, j'ai commencé à remarquer des points de douleur qui m'ont fait réaliser tous les endroits où je ne séparais pas correctement les préoccupations, faire un usage approprié des interfaces, et autrement rendre mon code modulaire et refactorisable.
TDD est également l'une de ces choses qui est difficile à voir l'avantage d'abord. Vous pensez: «Je sais déjà ce que je m'attends à faire de cette méthode, elle fait ce que je m'attends à faire, pourquoi devrais-je la tester? Mais quand vous commencez à écrire un test unitaire, vous êtes obligé d'y penser en termes de "Quelle entrée pourrais-je obtenir dans cette méthode" et "Que ferais-je avec?" Vous commencez à réaliser dans certains cas que vous devriez probablement lancer un type d'exception particulier au début de la méthode, plutôt que de permettre à la méthode de retourner un ensemble vide (ce que le consommateur ne devrait jamais attendre). Ou vous réalisez que la façon dont vous avez écrit cette classe rend impossible le test unitaire, et il existe en réalité une bien meilleure façon de le configurer, ce qui réduit la complexité. En fin de compte, vous obtenez beaucoup mieux à l'écriture de votre code, et écrire vos tests unitaires est si rapide que ce n'est pas une grosse douleur du tout. En fait, vos tests unitaires fournissent une meilleure documentation sur le comportement attendu de votre code que si vous écriviez de gros blocs de commentaires. En plus de cela, je trouve que même sur les méthodes "simples" que je pense que je ne pouvais pas avoir mal écrites, les tests unitaires trouvent un bug environ 50% du temps.
Cela a pris beaucoup de temps et beaucoup de travail, mais notre code est de bien meilleure qualité et sera beaucoup plus facile à maintenir, simplement parce que les tests DI et tests unitaires nous ont obligés à mieux séparer le code.
Modifier
Je dois aussi mentionner que nous avons été en mesure de tirer parti de l'injection de dépendance à faire des choses qui auraient été à peu près impossible avant. Par exemple, j'ai juste fait en sorte que lorsque des actions sont prises par un travail Quartz, elles apparaissent comme ayant été effectuées par une «personne système» spécifique pour un domaine spécifique. Si je me référais constamment à "HttpContext.Current" ou même à une classe d'utilitaires qui s'y réfèrent, je n'aurais pas été capable de le faire. Mais comme nous utilisons DI, n'importe quelle classe peut simplement dépendre d'un ISessionManager, et le noyau du conteneur de l'IoC peut décider s'il doit utiliser l'implémentation basée sur HttpContext ou un gestionnaire de session spécial "Système".
Il y a un certain nombre de trucs comme celui-ci qui nous ont rendu la vie beaucoup plus facile.Par exemple, nous n'avons pas besoin de dire à chaque instance d'enregistreur dans quelle classe il se trouve, car l'infrastructure d'ID peut indiquer automatiquement à quelle classe il est injecté. Je pourrais continuer encore et encore. En supposant que vous faites DI "la bonne façon", vous serez finalement surpris que vous avez déjà programmé d'une autre manière.