Est ServiceLocator un anti-modèle?

J'ai lu récemment Marque Seemann de l'article sur le Service Localisateur anti-modèle.

Auteur souligne deux principales raisons pour lesquelles les ServiceLocator est un anti-pattern:

D'utilisation de l'API question (dont je suis parfaitement bien avec)

Quand la classe emploie un localisateur de Service, il est très dur de voir ses dépendances, dans la plupart des cas, la classe n'a qu'un constructeur sans paramètre.
En contraste avec ServiceLocator, DI approche exposer explicitement les dépendances via les paramètres du constructeur si les dépendances sont facile vu dans IntelliSense.
Problème d'entretien (ce qui m'intrigue, c')

Considérez les points suivants expample

Nous avons une classe 'MyType' qui emploie un localisateur de Service d'approche:

public class MyType
{
    public void MyMethod()
    {
        var dep1 = Locator.Resolve<IDep1>();
        dep1.DoSomething();
    }
}

Maintenant, nous voulons ajouter une autre dépendance à la classe de MyType'

public class MyType
{
    public void MyMethod()
    {
        var dep1 = Locator.Resolve<IDep1>();
        dep1.DoSomething();

        //new dependency
        var dep2 = Locator.Resolve<IDep2>();
        dep2.DoSomething();
    }
}

Et c'est là où mon incompréhension commence. L'auteur dit:

Il devient beaucoup plus difficile de dire si vous êtes l'introduction d'une modification de rupture ou non. Vous avez besoin de comprendre l'ensemble de l'application dans laquelle le Service Locator est utilisée, et que le compilateur ne va pas vous aider.

Mais attendez une seconde, si nous étions à l'aide de DI approche, nous allons introduire une dépendance avec un autre paramètre dans le constructeur (dans le cas du constructeur d'injection). Et le problème sera toujours là. Si l'on peut oublier de configurer ServiceLocator, alors on peut oublier d'ajouter une nouvelle cartographie dans notre conteneur IoC et DI approche aurait le même problème de temps.

Aussi, l'auteur a mentionné à propos de l'unité de test de difficultés. Mais, ne nous ont des problèmes avec DI approche? Ne portons-nous pas besoin de mettre à jour tous les tests qui ont été l'instanciation de cette classe? Nous avons mis à jour à passer un nouveau moqué de dépendance juste pour faire notre test compilable. Et je ne vois pas les avantages de cette mise à jour et de passer du temps.

Je ne suis pas en train de défendre le Service Localisateur d'approche. Mais cette incompréhension me font penser que je vais perdre quelque chose de très important. Quelqu'un pourrait dissiper mes doutes?

MISE À JOUR (RÉSUMÉ):

La réponse à ma question "Est le Service Localisateur d'un anti-pattern" dépend vraiment de la situation. Et je ne dirais pas pour la rayer de votre liste d'outils. Il peut être très pratique lorsque vous commencez à traiter avec le code existant. Si vous êtes assez chanceux pour être au tout début de votre projet, alors les DI approche pourrait être un meilleur choix car il a certains avantages par rapport au Service Locator.

Et ici sont les principales différences qui m'a convaincu de ne pas utiliser le Service de Localisateur pour mes nouveaux projets:

Le plus évident et important: le Service Localisateur de masque de classe dépendances
Si vous êtes en utilisant un conteneur IoC, il ne sera probablement analyser tous les constructeur au démarrage afin de valider l'ensemble des dépendances et de vous donner de la rétroaction immédiate manquant mappages (ou de la mauvaise configuration); ce n'est pas possible si vous utilisez votre conteneur IoC en tant que Service Locator

Pour plus de détails lire d'excellentes réponses qui sont données ci-dessous.

"N'avons-nous pas besoin de mettre à jour tous les tests qui ont été l'instanciation de cette classe?" Pas nécessairement vrai si vous utilisez un générateur dans vos tests. Dans ce cas, vous n'avez qu'à mettre à jour le générateur de rapports.
Vous avez raison, ça dépend. Dans les grandes applications Android, par exemple, jusqu'à présent, les gens ont été très réticents à utiliser DI en raison de problèmes de performances sur les bas spec appareils mobiles. Dans de tels cas, vous devez trouver une alternative à toujours écrire de code de tests, et je dirais Service Locator est un bon-assez de substitution dans ce cas. (Note: les choses peuvent changer pour Android quand la nouvelle de la Dague 2.0 DI-cadre est assez mature.)
Notez que depuis que cette question a été posté, il y a une mise à jour sur la Marque Seemann Service Locator est un Anti-Patron de la poste décrivant la façon dont le service localisateur de viole de la programmation orientée objet par briser l'encapsulation, qui est son meilleur argument encore (et la raison sous-jacente de tous les symptômes qu'il a utilisé dans tous les avant les arguments). mise à Jour 2015-10-26: Le problème fondamental avec le Service Locator, c'est qu'il viole l'encapsulation.

OriginalL'auteur davidoff | 2014-04-01

114

Si vous définir des modèles comme les anti-modèles juste parce qu'il y a certaines situations où il n'est pas bon, alors, OUI, c'est un anti-modèle. Mais avec ce raisonnement, tous les modèles serait aussi anti-modèles.

Au contraire, nous devons regarder si il y a valide les usages des modèles, et pour le Service Locator il y a plusieurs cas d'utilisation. Mais nous allons commencer par regarder les exemples que vous avez donné.
```
public class MyType
{
    public void MyMethod()
    {
        var dep1 = Locator.Resolve<IDep1>();
        dep1.DoSomething();

        //new dependency
        var dep2 = Locator.Resolve<IDep2>();
        dep2.DoSomething();
    }
}
```
L'entretien cauchemar avec cette classe, c'est que les dépendances sont cachés. Si vous créez et l'utilisation de cette classe:
```
var myType = new MyType();
myType.MyMethod();
```
Vous ne comprenez pas qu'il a des dépendances s'ils sont masqués à l'aide de l'emplacement du service. Maintenant, si nous avons plutôt utiliser l'injection de dépendance:
```
public class MyType
{
    public MyType(IDep1 dep1, IDep2 dep2)
    {
    }

    public void MyMethod()
    {
        dep1.DoSomething();

        //new dependency
        dep2.DoSomething();
    }
}
```
Vous pouvez directement spot les dépendances et ne peut pas utiliser les classes avant de le satisfaire.

Dans une ligne typique d'application d'entreprise, vous devez éviter l'utilisation de services de localisation pour cette raison. Il devrait être le modèle à utiliser quand il n'y a pas d'autres options.

Est le modèle d'un anti-modèle?

Pas.

Par exemple, l'inversion de contrôle des conteneurs ne pourrait pas fonctionner sans le service de localisation. C'est la façon dont ils résolvent les services en interne.

Mais un bien meilleur exemple est ASP.NET MVC et WebApi. Que pensez-vous fait de l'injection de dépendance possible dans les contrôleurs? C'est là que l'emplacement du service.

Vos questions

Mais attendez une seconde, si nous étions à l'aide de DI approche, nous allons introduire un
dépendance avec un autre paramètre dans le constructeur (dans le cas de
constructeur d'injection). Et le problème sera toujours là.

Il y a deux problèmes plus graves:
1. Avec l'emplacement de service vous sont également l'ajout d'une autre dépendance: Le service de localisation.
2. Comment dites-vous dont la durée de vie des dépendances doit avoir, et comment/quand ils devraient obtenir nettoyé?
Avec le constructeur d'injection à l'aide d'un conteneur de vous gratuit.

Si l'on peut
oublier de configurer ServiceLocator, alors on peut oublier d'ajouter un nouveau
la cartographie dans notre conteneur IoC et DI approche aurait le même
au moment de l'exécution problème.

C'est vrai. Mais avec le constructeur injection, vous n'avez pas de scanner l'ensemble de la classe pour savoir qui dépendances manquantes.

Et certains mieux conteneurs également de valider l'ensemble des dépendances au démarrage (par l'analyse de tous les constructeurs). Donc, avec ces conteneurs, vous obtenez l'erreur d'exécution directement, et pas plus tard temporelle point.

Aussi, l'auteur a mentionné à propos de l'unité de test de difficultés. Mais, ne nous ont des problèmes avec DI approche?

Pas. Comme vous n'avez pas de dépendance à un service statique de localisation. Avez-vous essayé d'obtenir des tests en parallèle de travail statique des dépendances? Ce n'est pas amusant.

Jgauffin, merci pour votre réponse. Vous l'avez souligné une chose importante à propos de vérification automatique au démarrage. Je n'ai pas à réfléchir à ce sujet et maintenant je vois un autre avantage de la DI. Vous avez également donné un exemple: "var myType = new MyType()". Mais je ne peux pas le considérer comme valable l'une que nous n'avons jamais instancier des dépendances dans une application réelle (Conteneur IoC t-il pour nous tout le temps). I. e: en application MVC, nous avons un contrôleur, qui charge sur IMyService et MyServiceImpl dépend IMyRepository. Nous ne serons jamais à instancier MyRepository et MyService. Nous obtenir des instances de Ctor params (à l'instar de ServiceLocator) et de les utiliser. N'est-ce pas?
Votre seul argument pour le Service Localisateur de ne pas être un anti-modèle est la suivante: "l'inversion de contrôle des conteneurs ne pourrait pas fonctionner sans le service de localisation". Cet argument est cependant pas valide, puisque le Service Locator est sur les intentions et non pas sur la mécanique, comme l'explique clairement ici par Mark Seemann: "UN conteneur d'injection de dépendances encapsulé dans une Composition de la Racine n'est pas un Localisateur de Service - c'est une composante de l'infrastructure."
Web API ne pas utiliser le Service de Localisation pour les DI dans les Contrôleurs. Il ne fait pas de DI. Ce qu'il fait est: Il vous donne la possibilité de créer vos propres ControllerActivator de passer dans la Configuration des Services. À partir de là, vous pouvez créer une composition de racine, qu'il soit Pur, DI, ou dans des Conteneurs. Aussi, vous sont un mélange de l'utilisation de l'Emplacement du Service, en tant que composante de votre modèle, avec la définition de "Service de Patron de localisation." Avec cette définition, la Composition de la Racine DI peut être considéré comme un "Service Patron de localisation." Donc tout l'intérêt de cette définition est discutable.
Je veux souligner que c'est généralement une bonne réponse, j'ai juste commenté un trompeur point que vous avez fait.
DI et SL sont les deux version de "restitutions" de la Coi. SL est juste le mal moyen de le faire. Un conteneur IoC être SL, ou il pourrait utiliser DI. Cela dépend de comment c'est câblé. Mais SL est mauvais, mauvais, mauvais. C'est une façon de cacher le fait que vous êtes étroitement associant tout ensemble.

OriginalL'auteur jgauffin
36

Je tiens également à souligner que, SI vous êtes à la refactorisation de code hérité que le Service Locator modèle n'est pas seulement un anti-modèle, mais c'est aussi une nécessité pratique. Personne ne va jamais de vague d'un coup de baguette magique sur des millions de lignes de code et tout à coup ce code va être DI prêt. Donc, si vous voulez commencer à introduire le DI à une base de code, c'est souvent le cas que l'on va changer les choses pour devenir DI services lentement, et le code qui fait référence à ces services souvent de ne PAS être DI services. D'où CES services, vous devrez utiliser le Localisateur de Service afin d'obtenir des instances de ces services qui ONT été converties pour utiliser les DI.

Donc lors d'un refactoring de grandes applications de commencer à utiliser DI concepts, je dirais que non seulement Localisateur de Service n'est PAS un anti-modèle, mais que c'est la seule façon de l'appliquer progressivement DI concepts à la base de code.

Lorsque vous faites affaire avec le code existant, tout est justifié pour vous sortir de ce gâchis, même si cela signifie la prise intermédiaire (et imparfait). Le Service Locator est telle étape intermédiaire. Il vous permet de vous sortir de cet enfer, une étape à la fois, aussi longtemps que vous vous souvenez qu'une bonne solution alternative existe et qu'il est documenté, reproductible et prouvé pour être efficace. Cette solution alternative est d'Injection de Dépendance et c'est précisément pourquoi le Service Locator est encore un anti-modèle; correctement conçu le logiciel n'utilise pas cette.

OriginalL'auteur jwells131313
7

De l'essai de point de vue, Localisateur de Service est mauvais. Voir Misko Hevery Google Tech Talk belle explication avec des exemples de code http://youtu.be/RlfLCWKxHJ0 de départ à la minute 8:45. J'ai aimé son analogie: si vous avez besoin de 25$, demander directement de l'argent plutôt que de donner à votre portefeuille d'où l'argent sera pris en compte. Il compare également Localisateur de Service avec une botte de foin qui a l'aiguille que vous avez besoin et sait comment faire pour le récupérer. Les Classes à l'aide de Localisateur de Service sont difficiles à réutiliser à cause de cela.

C'est un papier recyclé avis et aurait été mieux comme commentaire. Aussi, je pense que votre (son?) l'analogie sert à prouver que certains modèles sont plus appropriés pour certains problèmes sur les autres.

OriginalL'auteur user3511397
4

Problème d'entretien (ce qui m'intrigue, c')

Il y a 2 raisons pour lesquelles l'aide de localisateur de service est mauvais dans ce domaine.
1. Dans votre exemple, vous êtes de coder en dur une référence statique pour le service locator dans votre classe. Cette étroitement les couples votre classe directement le service locator, qui à son tour signifie il ne fonctionne pas sans le service locator. En outre, des tests unitaires (et personne d'autre qui utilise la classe) sont également implicitement dépend le service locator. Une chose qui semble passer inaperçu ici, c'est que lors de l'utilisation de constructeur injection, vous n'avez pas besoin d'un conteneur d'injection de dépendances lors de tests unitaires, ce qui simplifie la gestion de vos tests unitaires (et les développeurs de la capacité à les comprendre) considérablement. Qu'est réalisé le test unitaire avantage que vous obtenez de l'aide du constructeur d'injection.
2. Comme pour pourquoi constructeur Intellisense est important, les gens ici semblent avoir manqué le point entièrement. Une classe est écrite une fois, mais il peut être utilisé dans plusieurs applications (qui est, plusieurs DI configurations). Au fil du temps, il verse des dividendes si vous pouvez regarder le constructeur définition de comprendre les dépendances d'une classe, plutôt que de le regarder (je l'espère à jour) documentation ou, à défaut, vers le code source d'origine (ce qui pourrait ne pas être pratique) pour déterminer les dépendances d'une classe. La classe avec le service locator est généralement plus facile à écrire, mais plus que de payer le coût de cette pratique dans l'entretien continu du projet.
Clair et simple: Une classe avec un localisateur de service est plus difficile à réutiliser que celui qui accepte ses dépendances par le biais de son constructeur.

Considérons le cas où vous avez besoin d'utiliser un service de LibraryA que son auteur a décidé de utiliseraient ServiceLocatorA et un service de LibraryB dont l'auteur a décidé utiliserait ServiceLocatorB. Nous n'avons pas d'autre choix que d'utiliser 2 services différents repérages dans notre projet. Combien de dépendances doivent être configurés est un jeu de devinettes si nous n'avons pas une bonne documentation, le code source, ou de l'auteur sur le cadran de vitesse. À défaut de ces options, nous pourrions avoir besoin d'utiliser un décompilateur juste à comprendre ce que les dépendances sont. Nous pouvons avoir besoin de configurer les 2 entièrement différente service locator Api, et en fonction de la conception, il peut ne pas être possible de simplement envelopper votre conteneur d'injection de dépendances. Il peut ne pas être possible à tous de partager une instance d'une dépendance entre les deux bibliothèques. La complexité du projet pourrait même être aggravé si le service des localisateurs ne n'arrive pas à réellement résider dans les mêmes bibliothèques que les services dont nous avons besoin - nous sommes implicitement glisser d'autres références de bibliothèque dans notre projet.

Considérons maintenant les deux mêmes services faite avec du constructeur d'injection. Ajouter une référence à LibraryA. Ajouter une référence à LibraryB. Fournir les dépendances dans votre DI configuration (par l'analyse de ce qui est nécessaire via Intellisense). Fait.

Marque Seemann a un StackOverflow réponse qui illustre clairement cette prestation sous forme de graphiques, qui ne s'applique pas uniquement lors de l'utilisation d'un localisateur de service à partir d'une autre bibliothèque, mais aussi lors de l'utilisation des valeurs par défaut dans les services.

OriginalL'auteur NightOwl888
1

Ma connaissance n'est pas assez bon pour en juger, mais en général, je pense que si quelque chose a une utilisation dans une situation particulière, il ne signifie pas nécessairement qu'il ne peut pas être un anti-modèle. En particulier, lorsque vous traitez avec de la 3e partie des bibliothèques, vous n'avez pas le plein contrôle sur tous les aspects et vous pouvez vous retrouver à l'aide de la pas la meilleure solution.

Voici un paragraphe de Adaptative Code Via C#:

"Malheureusement, le service locator est parfois inévitable dans l'anti-modèle. Dans certains types d'applications— en particulier Windows Workflow Foundation— l'infrastructure ne se prête pas au constructeur de l'injection. Dans ces cas, la seule alternative est d'utiliser un localisateur de service. C'est mieux que de ne pas l'injection de dépendances. Pour tous mes vitriol contre le (anti-) le motif, c'est infiniment mieux que manuellement la construction de dépendances. Après tout, il permet toujours des points d'extension fournis par des interfaces qui permettent de décorateurs, cartes, et autres avantages similaires."

-- Hall, Gary McLean. Adaptative Code via C#: développement Agile, avec des modèles de conception et des principes SOLIDES (Développeur de Référence) (p. 309). Pearson Education.

OriginalL'auteur Siavash Mortazavi
0

L'Auteur soutient que "le compilateur ne sera pas vous aider" - et c'est vrai.
Lorsque vous daignez une classe, vous aurez envie de choisir avec soin son interface - parmi d'autres objectifs pour le rendre le plus indépendant ... que ça fait du sens.

En amenant le client à accepter la référence à un service (une dépendance) explicite de l'interface, vous
- implicitement obtenir la vérification, de sorte que le compilateur "aide".
- Vous êtes aussi en supprimant la nécessité pour le client de savoir quelque chose au sujet de la "Locator" ou de mécanismes similaires, de sorte que le client est en fait de plus en plus indépendante.
Vous avez raison, la DI a ses problèmes et inconvénients, mais les avantages l'emportent sur eux, et de loin ... de l'OMI.
Vous avez raison, qu'avec DI il y a une dépendance introduit dans l'interface (constructeur) - mais ce n'est, espérons-le, très dépendance que vous avez besoin et que vous souhaitez rendre visible et vérifiable.

Zrin, merci pour vos pensées. Ce que je comprends, avec un "bon" DI approche que je ne devrait pas instancier mon dépendances n'importe où à l'exception des tests unitaires. Ainsi, le compilateur va m'aider à seul avec mes tests. Mais comme je l'ai indiqué dans ma question initiale, cette "aide" avec des tests cassés ne me donne rien. N'est ce pas?
Le 'statique'/'au moment de la compilation vérification de l'argument est un homme de paille. @Davidoff a souligné, DI est également sensibles à des erreurs d'exécution. Je voudrais également ajouter que les Ide modernes fournir de l'info-bulle des vues de commentaire/résumé informations pour les membres, et même dans ceux qui n'en ont pas, quelqu'un va toujours être à la recherche à la documentation jusqu'à ce qu'elles "savent" de l'API. Documentation la documentation, si nécessaire paramètre du constructeur ou une remarque sur la façon de configurer une dépendance.
La réflexion sur la mise en œuvre de codage et d'assurance de la qualité - la lisibilité du code est un élément crucial, en particulier pour la définition de l'interface. Si vous pouvez faire sans automatique de la compilation des contrôles et si vous le faites de manière adéquate commentaire / document de votre interface, alors je suppose que vous pouvez au moins partiellement remédier aux inconvénients de l'cachée de la dépendance sur un type de variable globale avec pas facilement visible et prévisible contenu. Je dirais que vous avez besoin de bonnes raisons pour utiliser ce modèle qui l'emportent sur les inconvénients de cette.

OriginalL'auteur Zrin
0

Oui, localisateur de service est un anti-pattern, il viole l'encapsulation et solide.

Je comprends ce que tu veux dire, mais il serait utile d'ajouter plus de détails, par exemple, pourquoi il viole SOLIDE

OriginalL'auteur Alireza Rahmani Khalili

Vous devez vous connecter pour publier un commentaire.

Est le modèle d'un anti-modèle?

Vos questions