Ist ServiceLocator ein anti-pattern?

Kürzlich habe ich gelesen Mark Seemann Artikel über den Service Locator anti-pattern.

Autor weist hauptsächlich zwei Gründe, warum ServiceLocator ist ein anti-Muster:

API-Nutzung-Problem (was ich völlig in Ordnung)
Wenn die Klasse beschäftigt ein Service locator ist es sehr schwer zu erkennen, Ihre Abhängigkeiten, wie in den meisten Fällen-Klasse hat nur einen PARAMETERLOSEN Konstruktor.
Im Gegensatz ServiceLocator, DI-Ansatz explizit aussetzen Abhängigkeiten per Konstruktor-Parameter also, die Abhängigkeiten sind einfach gesehen, in IntelliSense.
Wartung Problem (das verwirrt mich)
Betrachten Sie das folgende zB

Wir haben eine Klasse 'MyType', die mit einem Service-locator-Ansatz:

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

Nun wollen wir hinzufügen, eine andere Abhängigkeit zu der Klasse 'MyType'

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

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

Und hier ist, wo mein Unverständnis beginnt. Der Autor sagt:

Wird es viel schwieriger zu sagen, ob Sie die Einführung einer brechen ändern oder nicht. Sie müssen verstehen, dass die gesamte Anwendung, in denen der Service-Locator verwendet wird, und der compiler ist nicht zu helfen.

Aber warten Sie eine Sekunde, wenn wir mit DI-Ansatz, würden wir die Einführung einer Abhängigkeit mit einem anderen parameter im Konstruktor (bei der constructor injection). Und das problem wird noch da sein. Wenn wir vielleicht vergessen, um das setup ServiceLocator, dann können wir vergessen, fügen Sie eine neue Zuordnung in unserer IoC-container und DI-Ansatz würde die gleiche Laufzeit-problem.

Außerdem Autor erwähnt über unit-test Schwierigkeiten. Aber, nicht wir haben Probleme mit der DI-Ansatz? Nicht wir müssen aktualisieren Sie alle tests wurden Instanziierung dieser Klasse? Wir werden aktualisiert und vermitteln ein neues verspottet Abhängigkeit nur um unseren test kompilierbar. Und ich sehe keine Vorteile von diesem update und Zeit verbringen.

Ich versuche nicht zu verteidigen Service-Locator-Ansatz. Aber dieses Missverständnis machen mich denken, dass ich etwas zu verlieren sehr wichtig. Könnte jemand zerstreuen meine Zweifel?

UPDATE (ZUSAMMENFASSUNG):

Die Antwort auf meine Frage "Ist das Service-Locator-ein anti-pattern" hängt nun wirklich von den Umständen ab. Und ich definitiv nicht empfehlen kann, ist zu überqueren, es aus der Werkzeug-Liste. Es könnte sehr nützlich sein, wenn Sie beginnen, den Umgang mit legacy-code. Wenn Sie Glück genug, um am Anfang Ihr Projekt dann bei der DI-Ansatz wäre die bessere Wahl, da es einige Vorteile gegenüber den Service-Locator.

Und hier sind die wichtigsten Unterschiede, die mich überzeugt, nicht die Nutzung des Service Locator für meine neuen Projekte:

Die meisten offensichtlich und wichtig: Service Locator blendet Klasse Abhängigkeiten
Wenn Sie Verwendung einigen IoC-container, wird es wahrscheinlich Scannen Sie alle Konstruktor beim Start überprüft alle Abhängigkeiten und geben Ihnen sofortiges feedback auf fehlende mappings (oder falsche Konfiguration); dies ist nicht möglich, wenn Sie Ihre IoC-container als Service Locator

Für details Lesen Sie hervorragende Antworten, die sind unten angegeben.

"Nicht wir müssen aktualisieren Sie alle tests wurden Instanziierung dieser Klasse?" Nicht unbedingt wahr, wenn Sie mit einem generator in Ihren tests. In diesem Fall würden Sie nur das update-generator.
Du hast Recht, es hängt davon ab. In großen Android-apps, zum Beispiel, so weit die Menschen waren sehr zurückhaltend mit DI wegen der Leistung Bedenken, die auf low-spec-mobile-Geräte. In solchen Fällen müssen Sie eine Möglichkeit finden, noch schreiben von testbarem code, und ich würde sagen, Service Locator ist ein gut-genug Ersatz in diesem Fall. (Hinweis: die Dinge können sich ändern für Android, wenn die neuen Dolch 2.0 DI-framework ist ausgereift genug.)
Beachten Sie, dass, da diese Frage schon gepostet hat, gibt es ein update auf Mark Seemann Service Locator ist ein Anti-Pattern-post - beschreibt, wie service-locator gegen OOP durch Aufbrechen der Kapselung, das ist seine beste argument noch (und der eigentliche Grund für all die Symptome, die er verwendet, werden alle vorherigen Argumente). Update 2015-10-26: Das grundlegende problem mit dem Service Locator ist, dass es gegen Kapselung.

InformationsquelleAutor davidoff | 2014-04-01

114

Wenn Sie definieren Muster als anti-mustern, nur weil es einige Situationen, wo es nicht passt, dann JA, es ist ein anti-pattern. Aber mit dieser Argumentation alle Muster wäre auch anti-Muster.

Stattdessen müssen wir schauen, ob es gültige Verwendungen der Muster und für den Service Locator gibt es verschiedene Anwendungsfälle. Aber lassen Sie uns beginnen, indem man die Beispiele, die Sie gegeben haben.
```
public class MyType
{
    public void MyMethod()
    {
        var dep1 = Locator.Resolve<IDep1>();
        dep1.DoSomething();

        //new dependency
        var dep2 = Locator.Resolve<IDep2>();
        dep2.DoSomething();
    }
}
```
Den Wartungs-Alptraum mit dieser Klasse ist, dass die Abhängigkeiten ausgeblendet sind. Wenn Sie erstellen und verwenden Sie diese Klasse:
```
var myType = new MyType();
myType.MyMethod();
```
Du nicht verstehen, dass es Abhängigkeiten, wenn Sie ausgeblendet sind mit service-Standort. Nun, wenn wir statt dependency injection:
```
public class MyType
{
    public MyType(IDep1 dep1, IDep2 dep2)
    {
    }

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

        //new dependency
        dep2.DoSomething();
    }
}
```
Können Sie direkt vor Ort die Abhängigkeiten und können nicht verwenden Sie die Klassen vor befriedigend.

In einer typischen line-of-business-Anwendung, die Sie sollten vermeiden, die Verwendung von service-Standort für den jeweiligen Anlass. Sollte es sein, die Muster zu verwenden, wenn es keine anderen Optionen.

Ist das pattern ein anti-pattern?

Nicht.

Beispielsweise inversion of control Container nicht funktionieren würde, ohne service-Standort. Es ist, wie Sie lösen die services intern.

Aber ein viel besseres Beispiel ist ASP.NET MVC und WebApi. Was denken Sie, macht die dependency injection möglich in den Controller? Das stimmt -, service-Standort.

Ihre Fragen

Aber warten Sie eine Sekunde, wenn wir mit DI-Ansatz, würden wir die Einführung einer
Abhängigkeit mit einem anderen parameter im Konstruktor (im Fall von
constructor injection). Und das problem wird noch da sein.

Gibt es noch zwei weitere schwerwiegende Probleme:
1. Mit service-Standort, Sie sind auch das hinzufügen einer weiteren Abhängigkeit: Der service locator.
2. Wie Sie sagen, welche Lebensdauer die Abhängigkeiten haben sollte und wie/Wann sollten Sie bereinigt werden?
Mit Konstruktor-Injektion mit Hilfe eines Containers, die Sie bekommen, kostenlos.

Wenn wir dürfen
vergessen Sie auf setup ServiceLocator, dann können wir vergessen, um neue hinzuzufügen
die Zuordnung in unserer IoC-container und DI-Ansatz würden die gleichen
Laufzeit-problem.

Das ist wahr. Aber mit Konstruktor-Injektion, die Sie nicht Scannen die gesamte Klasse, um herauszufinden, welche Abhängigkeiten fehlen.

Und einige bessere Container auch überprüft alle Abhängigkeiten beim Start (durch das Scannen aller Konstruktoren). Also mit diesen Behältern erhalten Sie die runtime-Fehler direkt, und nicht auf einige spätere zeitliche Punkt.

Außerdem Autor erwähnt über unit-test Schwierigkeiten. Aber, nicht wir haben Probleme mit der DI-Ansatz?

Nicht. Da Sie nicht über die eine Abhängigkeit zu einer statischen service-locator. Haben Sie versucht, um parallele tests arbeiten mit statischen Abhängigkeiten? Es ist nicht Spaß.

Jgauffin, vielen Dank für deine Antwort. Sie wies eine wichtige Sache, über auto-check am Start. Ich habe nicht nachgedacht, und jetzt sehe ich einen weiteren Vorteil von DI. Sie gab auch ein Beispiel: "var myType = new MyType()". Aber ich kann nicht zählen, es als gültig, wie wir es nie instantiate-Abhängigkeiten in einer realen app (IoC-Containers ist es für uns alle die Zeit). I. e: im MVC-app haben wir einen eigenen controller, der Angehörigen auf IMyService und MyServiceImpl hängt davon ab, IMyRepository. Wir werden nie instanziiert MyRepository und MyService. Wir erhalten Instanzen von Ctor params (wie von ServiceLocator) und verwenden Sie Sie. Tun wir das nicht?
Ihre einzige argument für den Service-Locator nicht als ein anti-pattern ist: "inversion of control Container nicht funktionieren würde, ohne service-Standort". Dieses argument ist jedoch ungültig, da der Service Locator wird über die Absichten und nicht um die mechanik, wie bereits erläutert, klar hier von Mark Seemann: "EIN DI-container gekapselt in einer Komposition Root ist nicht ein Service-Locator - es ist eine Infrastruktur-Komponente."
Web-API nicht verwenden Service-Standort für die DI in Controller. Es nicht, DI an alle. Was es tut, ist: Es gibt Ihnen die option zum erstellen Ihrer eigenen ControllerActivator Durchgang in der Configuration Services. Von dort aus können Sie eine Zusammensetzung root, ob es einen Reinen DI oder Container. Auch mischen Sie die Verwendung von Service-Standort, als Bestandteil Ihrer Muster, mit der definition von "Service-Locator-Muster." Mit dieser definition, Zusammensetzung Stamm-DI -, könnte erwogen werden, ein "Service-Locator-Muster." Der springende Punkt, die definition ist umstritten.
Ich möchte darauf hinweisen, dass dies eine allgemein gute Antwort, ich habe gerade kommentiert, eine irreführende Punkt, den Sie gemacht.
DI und SL sind beide Darstellungen des IoC. SL ist einfach die falsch Weg, es zu tun. Ein IoC-container könnte SL, oder es könnte DI. Es hängt davon ab, wie es verdrahtet. Aber SL ist schlecht, schlecht, schlecht. Es ist eine Weise des Versteckens der Tatsache, dass Sie eng Kupplung alles zusammen.

InformationsquelleAutor jgauffin
35

Möchte ich auch darauf hinweisen, dass, WENN Sie das refactoring von legacy-code, der den Service-Locator-Muster ist nicht nur ein anti-pattern, aber es ist auch eine praktische Notwendigkeit. Niemand ist jemals mit einem Zauberstab über Millionen von Zeilen code und plötzlich alle, der code wird DI bereit. Also, wenn Sie wollen, um zu starten Einführung von DI zu einem bestehenden code-Basis, ist es oft der Fall, dass Sie die Dinge ändern werden DI-Dienste langsam, und der code, die Verweise, die diese Dienste oft NICHT DI-Dienste. Damit DIESE services müssen die Service-Locator, um Instanzen dieser Dienste, die Sie HABEN umgewandelt worden, um die Verwendung DI.

Also bei der Umgestaltung großen legacy-Anwendungen zu nutzen beginnen DI-Konzepte, ich würde sagen, dass ist nicht nur Service-Locator NICHT ein anti-pattern, aber es ist der einzige Weg, um schrittweise gelten DI-Konzepte, um die code-Basis.

Wenn Sie den Umgang mit legacy code", alles ist gerechtfertigt, um Sie aus diesem Schlamassel, auch wenn es bedeutet, die Mittel (und unvollkommen) Schritte. Der Service Locator ist ein solcher Zwischenschritt. Es ermöglicht Ihnen, sich aus dieser Hölle einen Schritt in der Zeit, so lange wie Sie sich erinnern, dass ein gute alternative vorhanden ist, die dokumentiert, wiederholbar und bewährt. Diese alternative Lösung ist Dependency Injection und das ist genau, warum der Service Locator ist noch ein anti-pattern; richtig gestaltete software nicht verwenden Sie diese.

InformationsquelleAutor jwells131313
7

Sich aus der Prüfung Sicht -, Service-Locator ist schlecht. Sehen Misko Hevery Google Tech Talk schöne Erklärung mit Beispielen http://youtu.be/RlfLCWKxHJ0 ab minute 8:45. Ich mochte seine Analogie: wenn Sie $25, erfragen Sie bitte direkt bei Geld, anstatt Ihre Brieftasche aus, wo das Geld entnommen werden soll. Er vergleicht auch die Service-Locator mit einem Heuhaufen, der die Nadel, die Sie brauchen, und weiß, wie man es abrufen. - Klassen mit Service Locator sind schwer zu Wiederverwendung, weil es.

Dies ist eine recycelte Meinung gewesen und hätte besser als Kommentar. Außerdem denke ich, dass Ihre (seine?) die Analogie dient dazu, zu beweisen, dass einige Muster sind besser geeignet für einige Probleme, über andere.

InformationsquelleAutor user3511397
3

Wartung Problem (das verwirrt mich)

Gibt es 2 verschiedene Gründe, warum mit service locator ist schlecht in dieser Hinsicht.
1. In Ihrem Beispiel, Sie sind hart-Codierung eine statische Referenz auf die service-locator in Ihre Klasse. Diese fest Paare Ihrer Klasse direkt an den service-locator, was in Kurven bedeutet es wird nicht funktionieren ohne die service-locator -. Darüber hinaus können Sie Ihre unit-tests (und alle anderen, die mit der Klasse) sind implizit auch abhängig von den service-locator. Eine Sache, die schien, um unbemerkt zu bleiben, ist hier, dass bei der Verwendung von Konstruktor-Injektion, die Sie nicht brauchen, ein DI-container, wenn unit-Tests, die vereinfacht Ihre unit-tests (und die Entwickler mit der Fähigkeit, Sie zu verstehen) deutlich. Das ist die erkannte Einheit Prüfung Ihr nutzen aus der Verwendung von Konstruktor-Injektion.
2. Wie, warum Konstruktor Intellisense ist wichtig, Leute hier zu haben scheinen, vermisst den Punkt vollständig. Eine Klasse wird einmal geschrieben, aber es kann in mehreren Anwendungen eingesetzt (mehrere DI-Konfigurationen). Im Laufe der Zeit, es zahlt sich aus, wenn Sie an den Konstruktor-definition zu verstehen, den Abhängigkeiten einer Klasse, anstatt uns auf das (hoffentlich aktuelle) Dokumentation oder, gelingt das nicht, geht zurück zu den ursprünglichen source-code (die möglicherweise nicht praktisch sein), um zu bestimmen, was den Abhängigkeiten einer Klasse sind. Die Klasse mit der service locator ist in der Regel einfacher zu schreiben, aber Sie mehr als die Kosten für diese Bequemlichkeit, die in die laufende Pflege des Projektes.
Schlicht und einfach: Eine Klasse mit einem service locator es ist schwieriger wiederzuverwenden als eine, die akzeptiert Ihre Abhängigkeiten über den Konstruktor.

Betrachten wir den Fall, wo Sie brauchen, um einen Dienst von LibraryA dass sein Autor sich entschieden hätte verwenden ServiceLocatorA und ein service von LibraryB deren Autor entschied verwenden würde ServiceLocatorB. Wir haben keine andere Wahl, als mit 2 verschiedenen service-locators in unserem Projekt. Wie viele Abhängigkeiten konfiguriert werden müssen, ist ein Ratespiel, wenn wir keine gute Dokumentation, source code, oder der Autor auf Kurzwahl. Versagen diese Möglichkeiten, die wir möglicherweise benötigen, um ein decompiler nur, um herauszufinden, was die Abhängigkeiten sind. Wir können konfigurieren müssen 2 völlig verschiedene service-locator APIs, und je nach design, kann es nicht möglich sein, einfach wickeln Sie Ihre vorhandenen DI-container. Es kann nicht möglich sein, bei allen teilen eine Instanz einer Abhängigkeit zwischen den beiden Bibliotheken. Die Komplexität des Projekts könnte noch weiter verstärkt, wenn die service-Locator-Punkte passieren nicht tatsächlich befinden sich in der gleichen Bibliotheken wie die Dienstleistungen, die wir brauchen - wir sind implizit ziehen zusätzliche Bibliothek Verweise in unser Projekt.

Betrachten wir nun die gleichen zwei Dienste, die mit constructor injection. Fügen Sie einen Verweis auf LibraryA. Fügen Sie einen Verweis auf LibraryB. Die Abhängigkeiten, die in Ihrer DI-Konfiguration (indem Sie analysieren, was notwendig ist, über Intellisense). Getan.

Mark Seemann hat eine StackOverflow-Antwort, die deutlich illustriert diese Leistung in grafischer form, die nicht nur gilt, wenn Sie über einen service locator aus einer anderen Bibliothek, aber auch bei der Verwendung von fremden Vorgaben services.

InformationsquelleAutor NightOwl888
1

Mein wissen ist nicht gut genug, um zu beurteilen, aber im Allgemeinen denke ich, dass, wenn etwas hat eine Verwendung in einer bestimmten situation, es nicht notwendigerweise bedeutet, es kann nicht sein, ein anti-pattern. Vor allem, wenn man mit 3rd-party-Bibliotheken, die Sie nicht haben die volle Kontrolle über alle Aspekte und Sie können am Ende mit die nicht beste Lösung.

Hier ist ein Absatz von Adaptive Code Via C#":

"Leider ist der service locator ist manchmal eine unvermeidbare anti-pattern. In einigen Arten von Anwendungen, insbesondere Windows Workflow Foundation— die Infrastruktur eignet sich nicht darum constructor injection. In diesen Fällen, die einzige alternative ist die Verwendung eines service Locators. Das ist besser, als nicht zu injizierenden Abhängigkeiten überhaupt. Für alle my vitriol gegen die (anti-) Muster, es ist unendlich viel besser als manuell zu konstruieren Abhängigkeiten. Nachdem alle, die es noch ermöglicht, die so wichtige Erweiterungspunkte zur Verfügung gestellt von Schnittstellen, die es ermöglichen, Dekorateure, Adapter und ähnliche Leistungen."

-- Hall, Gary McLean. Adaptive Code via C#: Agile Programmierung mit design patterns und SOLID principles (Developer Reference) (S. 309). Pearson Education.

InformationsquelleAutor Siavash Mortazavi
0

Der Autor Gründe dafür, dass "der compiler wird dir nicht helfen" - und es ist wahr.
Wenn Sie geruhen, eine Klasse, werden Sie wollen, sorgfältig auswählen, seine Schnittstelle werden unter anderem die Ziele zu machen, wie unabhängig, wie ... wie es Sinn macht.

Durch, dass der client akzeptieren, den Verweis auf einen service (eine Abhängigkeit) durch explizite Schnittstelle, die Sie
- implizit erhalten überprüfen, damit der compiler "hilft".
- Sie entfernen auch die Notwendigkeit für die Kunden zu wissen, etwas über den "Locator" oder ähnliche Mechanismen, also der client eigentlich immer Unabhängiger werden.
Du hast Recht, dass DI hat seine Probleme /Nachteile, aber die genannten Vorteile überwiegen Sie bei weitem ... IMO.
Du hast Recht, das mit DI gibt es eine Abhängigkeit eingeführt, die in der Schnittstelle (Konstruktor) - aber das ist hoffentlich der Abhängigkeit, die Sie brauchen, und dass Sie möchten, machen Sie sichtbar und überprüfbar ist.

Zrin, vielen Dank für Ihre Gedanken. So wie ich das verstehe, mit einem "richtigen" DI-Ansatz, ich sollte nicht instanziiert, meine Abhängigkeiten überall, außer unit-tests. So, der compiler wird mir helfen, nur mit meinen tests. Aber wie beschrieben hab ich in meiner ursprünglichen Frage, diese "Hilfe" mit gebrochenen tests nicht, gibt mir nichts. Tut es das?
Die "statische " Informationen'/'compile-time checking' - argument ist ein Strohmann. @Davidoff hingewiesen hat, DI ist genauso anfällig für Laufzeitfehler. Ich möchte noch hinzufügen, dass moderne IDEs bieten tooltip Ansichten des Kommentar/Zusammenfassung Informationen für die Mitglieder, und sogar diejenigen, die nicht, jemand noch auf der Suche in der Dokumentation, bis Sie nur 'wissen' die API. Dokumentation ist die Dokumentation, ob ein erforderlicher parameter des Konstruktors oder einer Bemerkung über das konfigurieren einer Abhängigkeit.
Gedanken über die Umsetzung / Programmierung und Qualitätssicherung - die Lesbarkeit des Codes entscheidend ist, insbesondere zur definition der Schnittstelle. Wenn Sie das tun können ohne automatische Kompilier-Zeit überprüft und, wenn Sie angemessen kommentieren / dokumentieren Sie Ihre Schnittstelle, dann denke ich, kann man zumindest teilweise Abhilfe der Nachteile der versteckten Abhängigkeit auf eine Art Globale variable mit nicht leicht erkennbar / vorhersehbar Inhalte. Ich würde sagen, Sie brauchen gute Gründe, um diesem Muster überwiegen die Nachteile.

InformationsquelleAutor Zrin
0

Ja, service locator ist ein anti-pattern gegen Kapselung und solid.

Ich verstehe, was du meinst, aber es wäre hilfreich, wenn Sie weitere Details hinzufügen, z.B. warum Sie gegen SOLIDE

InformationsquelleAutor Alireza Rahmani Khalili

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.

Ist das pattern ein anti-pattern?

Ihre Fragen