De cette façon, j'écris ce code est testable, mais y a-t-il quelque chose qui ne va pas?

J'ai une interface appelée IContext. Aux fins de cela, peu importe ce qu'il fait, sauf ce qui suit:

T GetService<T>();

Cette méthode consiste à examiner le conteneur DI actuel de l'application et tente de résoudre la dépendance. Assez standard je pense.

Dans mon application ASP.NET MVC, mon constructeur ressemble à ceci.

protected MyControllerBase(IContext ctx)
{
    TheContext = ctx;
    SomeService = ctx.GetService<ISomeService>();
    AnotherService = ctx.GetService<IAnotherService>();
}

Donc, plutôt que d'ajouter plusieurs paramètres dans le constructeur pour chaque service (car cela deviendra vraiment ennuyeux et long pour les développeurs qui étendent l'application), j'utilise cette méthode pour obtenir des services.

Maintenant, ça ne va pas . Cependant, la façon dont je le justifie actuellement dans ma tête est la suivante - je peux me moquer .

Je peux. Il ne serait pas difficile de se moquer IContextpour tester le contrôleur. Je devrais quand même:

public class MyMockContext : IContext
{
    public T GetService<T>()
    {
        if (typeof(T) == typeof(ISomeService))
        {
            // return another mock, or concrete etc etc
        }

        // etc etc
    }
}

Mais comme je l'ai dit, ça ne va pas. Toutes pensées / abus bienvenus.

Avoir un au lieu de plusieurs paramètres dans le constructeur n'est pas la partie problématique de cette conception . Tant que votre IContextclasse n'est rien d'autre qu'une façade de service , spécialement pour fournir les dépendances utilisées dans MyControllerBase, et non un localisateur de service général utilisé dans tout votre code, cette partie de votre code est IMHO ok.

Votre premier exemple peut être changé en

protected MyControllerBase(IContext ctx)
{
    TheContext = ctx;
    SomeService = ctx.GetSomeService();
    AnotherService = ctx.GetAnotherService();
}

ce ne serait pas un changement de conception substantiel de MyControllerBase. Si cette conception est bonne ou mauvaise ne dépend que du fait si vous voulez

• assurez-vous TheContext, SomeServiceet AnotherServicesont toujours tous initialisés avec des objets fictifs, ou tous avec des objets réels
• ou, pour permettre leur initialisation avec différentes combinaisons des 3 objets (ce qui signifie, dans ce cas, vous devrez passer les paramètres individuellement)

Donc, utiliser un seul paramètre au lieu de 3 dans le constructeur peut être tout à fait raisonnable.

Ce qui pose problème, c'est d' IContextexposer la GetServiceméthode en public. À mon humble avis, vous devriez éviter cela, mais plutôt garder les "méthodes d'usine" explicites. Est-ce que ce sera ok pour implémenter les méthodes GetSomeServiceet GetAnotherServicede mon exemple en utilisant un localisateur de service? À mon humble avis, cela dépend. Tant que la IContextclasse continue d'être une simple fabrique abstraite dans le but spécifique de fournir une liste explicite d'objets de service, ce qui est acceptable à mon humble avis. Les usines abstraites ne sont généralement que du code «collé», qui n'a pas besoin d'être testé lui-même. Néanmoins, vous devriez vous demander si dans le contexte de méthodes comme GetSomeService, si vous avez vraiment besoin d'un localisateur de service, ou si un appel de constructeur explicite ne serait pas plus simple.

Alors, méfiez-vous, lorsque vous vous en tenez à une conception où l' IContextimplémentation n'est qu'un wrapper autour d'une GetServiceméthode générique publique , permettant de résoudre toutes les dépendances arbitraires par des classes arbitraires, alors tout s'applique à ce que @BenjaminHodgson a écrit dans sa réponse.

Cette conception est connue sous le nom de Service Locator * et je ne l'aime pas. Il y a beaucoup d'arguments contre:

Service Locator vous couple à votre conteneur . En utilisant l'injection de dépendance régulière (où le constructeur énonce explicitement les dépendances), vous pouvez remplacer simplement votre conteneur par un autre, ou revenir à new-expressions. Avec votre, IContextce n'est pas vraiment possible.

Service Locator masque les dépendances . En tant que client, il est très difficile de dire ce dont vous avez besoin pour construire une instance d'une classe. Vous avez besoin d'une sorte de IContext, mais vous devez également définir le contexte pour renvoyer les objets corrects afin de faire le MyControllerBasetravail. Ce n'est pas du tout évident de la signature du constructeur. Avec DI régulier, le compilateur vous dit exactement ce dont vous avez besoin. Si votre classe a beaucoup de dépendances, vous devriez ressentir cette douleur car elle vous incitera à refactoriser. Service Locator cache les problèmes liés aux mauvaises conceptions.

Service Locator provoque des erreurs d'exécution . Si vous appelez GetServiceavec un paramètre de type incorrect, vous obtiendrez une exception. En d'autres termes, votre GetServicefonction n'est pas une fonction totale. (Les fonctions totales sont une idée du monde FP, mais cela signifie essentiellement que les fonctions doivent toujours renvoyer une valeur.) Mieux vaut laisser le compilateur vous aider et vous dire quand vous avez des dépendances erronées.

Service Locator viole le principe de substitution Liskov . Parce que son comportement varie en fonction de l'argument type, Service Locator peut être vu comme s'il avait effectivement un nombre infini de méthodes sur l'interface! Cet argument est expliqué en détail ici .

Le localisateur de service est difficile à tester . Vous avez donné un exemple de faux IContextpour les tests, ce qui est bien, mais il est certainement préférable de ne pas avoir à écrire ce code en premier lieu. Injectez simplement vos fausses dépendances directement, sans passer par votre localisateur de services.

Bref, juste faites pas . Cela semble être une solution séduisante au problème des classes avec beaucoup de dépendances, mais à long terme, vous allez juste rendre votre vie misérable.

_{* Je définis Service Locator comme un objet avec une Resolve<T>méthode générique qui est capable de résoudre des dépendances arbitraires et est utilisé dans toute la base de code (pas seulement à la racine de composition). Ce n'est pas la même chose que Service Facade (un objet qui regroupe un petit ensemble connu de dépendances) ou Abstract Factory (un objet qui crée des instances d'un seul type - le type d'une Abstract Factory peut être générique mais la méthode ne l'est pas) .}

Les meilleurs arguments contre l'anti-modèle Service Locator sont clairement énoncés par Mark Seemann, donc je ne vais pas trop expliquer pourquoi c'est une mauvaise idée - c'est un voyage d'apprentissage que vous devez prendre le temps de comprendre par vous-même (je recommande également le livre de Mark ).

OK donc pour répondre à la question - reformulons votre problème réel :

Donc, plutôt que d'ajouter plusieurs paramètres dans le constructeur pour chaque service (car cela deviendra vraiment ennuyeux et long pour les développeurs qui étendent l'application), j'utilise cette méthode pour obtenir des services.

Il y a une question qui résout ce problème sur StackOverflow . Comme mentionné dans l'un des commentaires:

La meilleure remarque: "L'un des merveilleux avantages de l'injection de constructeur est qu'il rend les violations du principe de responsabilité unique manifestement évidentes."

Vous cherchez au mauvais endroit la solution à votre problème. Il est important de savoir quand une classe en fait trop. Dans votre cas, je soupçonne fortement qu'il n'y a pas besoin d'un "contrôleur de base". En fait, dans la POO, il y a presque toujours pas besoin d'héritage du tout . Les variations de comportement et de fonctionnalité partagée peuvent être entièrement obtenues grâce à une utilisation appropriée des interfaces, ce qui se traduit généralement par un code mieux factorisé et encapsulé - et pas besoin de transmettre des dépendances aux constructeurs de superclasses.

Dans tous les projets sur lesquels j'ai travaillé où il y a un contrôleur de base, cela a été fait uniquement dans le but de partager des propriétés et des méthodes pratiques, telles que IsUserLoggedIn()et GetCurrentUserId(). ARRÊTEZ . C'est une horrible mauvaise utilisation de l'héritage. Au lieu de cela, créez un composant qui expose ces méthodes et prenez une dépendance là où vous en avez besoin. De cette façon, vos composants resteront testables et leurs dépendances seront évidentes.

Mis à part toute autre chose, lors de l'utilisation du modèle MVC, je recommanderais toujours des contrôleurs maigres . Vous pouvez en savoir plus à ce sujet ici, mais l'essence du modèle est simple, les contrôleurs dans MVC ne devraient faire qu'une seule chose: gérer les arguments passés par le framework MVC, déléguer d'autres préoccupations à un autre composant. Il s'agit là encore du principe de responsabilité unique à l'œuvre.

Il serait vraiment utile de connaître votre cas d'utilisation pour porter un jugement plus précis, mais honnêtement, je ne peux penser à aucun scénario où une classe de base est préférable à des dépendances bien factorisées.

J'ajoute une réponse à cela sur la base des contributions de tous les autres. Merci beaucoup à tous. Voici d'abord ma réponse: "Non, il n'y a rien de mal à cela".

Réponse de Doc Brown "Service Facade" J'ai accepté cette réponse parce que ce que je cherchais (si la réponse était "non") était quelques exemples ou une extension de ce que je faisais. Il a fourni ceci en suggérant que A) il a un nom, et B) il y a probablement de meilleures façons de le faire.

Réponse de Benjamin Hodgson «Service Locator» Autant que j'apprécie les connaissances que j'ai acquises ici, ce que j'ai n'est pas un «Service Locator». Il s'agit d'une "façade de service". Tout dans cette réponse est correct mais pas pour mes circonstances.

Réponses USR

Je vais aborder cela plus en détail:

Vous abandonnez beaucoup d'informations statiques de cette façon. Vous reportez les décisions à l'exécution comme le font de nombreux langages dynamiques. De cette façon, vous perdez la vérification statique (sécurité), la documentation et le support d'outillage (auto-complétion, refactorings, recherche d'usages, flux de données).

Je ne perds aucun outillage et je ne perds pas de frappe "statique". La façade de service retournera ce que j'ai configuré dans mon conteneur DI, ou default(T). Et ce qu'il retourne est "tapé". La réflexion est encapsulée.

Je ne vois pas pourquoi l'ajout de services supplémentaires comme arguments du constructeur est un gros fardeau.

Ce n'est certainement pas "rare". Comme j'utilise un contrôleur de base , chaque fois que je dois changer de constructeur, je devrai peut-être changer 10, 100, 1000 autres contrôleurs.

Si vous utilisez un framework d'injection de dépendances, vous n'aurez même pas à passer manuellement les valeurs des paramètres. Là encore, vous perdez certains avantages statiques, mais pas autant.

J'utilise l'injection de dépendance. C'est le but.

Et enfin, le commentaire de Jules sur la réponse de Benjamin, je ne perds aucune flexibilité. C'est ma façade de service. Je peux ajouter autant de paramètres GetService<T>que je veux pour distinguer les différentes implémentations, tout comme on le ferait lors de la configuration d'un conteneur DI. Ainsi, par exemple, je pourrais changer GetService<T>()pour GetService<T>(string extraInfo = null)contourner ce "problème potentiel".

Quoi qu'il en soit, merci encore à tout le monde. Ça a été vraiment utile. À votre santé.