Dois-je utiliser des objets passés au constructeur pendant l'injection?

Question

Je comprends que l'un des moyens (peut-être les meilleurs) d'utiliser l'inversion de contrôle consiste à injecter les objets dépendants dans le constructeur (injection du constructeur).

Cependant, si je fais des appels à ces objets en dehors de de l'objet qui les utilise, j'ai l'impression de violer une sorte de règle - est-ce le cas? Je ne pense pas qu'il existe un moyen d'empêcher cela, mais devrais-je établir une règle qui (en dehors des objets moqués) nous ne devrions jamais appeler des méthodes de ces objets?

[EDIT] Voici un exemple simplifié de ce que je fais. J'ai un objet FileController qui est essentiellement utilisé pour le catalogage des fichiers. Il utilise un objet FileDal qui parle à la base de données pour insérer/interroger/mettre à jour les tables File et Directory.

Sur mon implémentation réelle, je construis le contrôleur en demandant à Castle d'utiliser une version SQL Server de la couche DAL. Dans mon test unitaire, j'utilise une version Sqlite en mémoire de la couche DAL. Cependant, en raison de la façon dont la couche DAL est implémentée, j'ai besoin d'appeler BeginTransaction et Commit autour de l'utilisation du FileController pour que la connexion ne soit pas fermée et que je puisse ensuite faire des récupérations et des assertions. Pourquoi je dois faire cela n'est pas très important, mais cela m'a amené à penser que l'appel de méthodes sur un objet DAL qui est utilisé par d'autres clients (contrôleurs) ne sonnait pas kasher. Voici un exemple:

FileDal fileDal = CastleFactory.CreateFileDal(); 
fileDal.BeginTransaction(); 
FileController fileController = new FileController(fileDal); 
fileController.CallInterestingMethodThatUsesFileDal(); 
fileDal.Commit(); 

Answer 1

Cela dépend vraiment du type d'objet - mais en général, je m'attends à ce que cela soit correct.

En effet, assez souvent, la même dépendance sera injectée dans de nombreux objets. Par exemple, si vous aviez un IAuthenticator et plusieurs classes nécessaires pour utiliser l'authentification, il serait logique de créer une seule instance et de l'injecter dans chacune des classes dépendantes, en supposant qu'elles aient besoin de la même configuration.

I typiquement trouve que mes dépendances sont des types immuables qui sont naturellement thread-safe. Ce n'est pas toujours le cas, bien sûr - et dans certains cas (avec certains conteneurs IoC, au moins), vous pouvez avoir des dépendances construites automatiquement pour un thread ou une session spécifique - mais les dépendances de type "service" devraient normalement être appelées à partir de plusieurs endroits et discussions.