Ostatnio przeczytałem artykuł Marka Seemanna na temat anty-wzorca Service Locator.

Autor wskazuje dwa główne powody, dla których ServiceLocator jest anty-wzorcem:

1. Problem z używaniem API (z którym jestem w porządku)
   Gdy klasa korzysta z lokalizatora usług, bardzo trudno jest zobaczyć jego zależności, ponieważ w większości przypadków klasa ma tylko jeden konstruktor BEZ PARAMETRÓW. W przeciwieństwie do ServiceLocator, podejście DI jawnie uwidacznia zależności za pośrednictwem parametrów konstruktora, dzięki czemu zależności są łatwo widoczne w IntelliSense.

2. Problem konserwacji (który mnie
   zastanawia ) Rozważ następujący przykład

Mamy klasę „MyType”, która wykorzystuje podejście do lokalizatora usług:

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

Teraz chcemy dodać kolejną zależność do klasy „MyType”

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

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

I tu zaczyna się moje nieporozumienie. Autor mówi:

O wiele trudniej jest stwierdzić, czy wprowadzasz przełomową zmianę, czy nie. Musisz zrozumieć całą aplikację, w której używany jest Lokalizator usług, a kompilator ci nie pomoże.

Ale poczekaj chwilę, gdybyśmy używali podejścia DI, wprowadzilibyśmy w konstruktorze zależność z innym parametrem (w przypadku iniekcji konstruktora). A problem nadal będzie istniał. Jeśli możemy zapomnieć o skonfigurowaniu ServiceLocator, możemy zapomnieć o dodaniu nowego mapowania w naszym kontenerze IoC, a podejście DI spowodowałoby ten sam problem w czasie wykonywania.

Autor wspomniał również o trudnościach z testami jednostkowymi. Ale czy nie będziemy mieli problemów z podejściem DI? Czy nie będziemy musieli aktualizować wszystkich testów, które tworzyły instancję tej klasy? Zaktualizujemy je tak, aby przekazywały nową, mockowaną zależność, aby nasz test był kompilowalny. I nie widzę żadnych korzyści z tej aktualizacji i spędzania czasu.

Nie próbuję bronić podejścia Service Locator. Ale to nieporozumienie sprawia, że ​​myślę, że tracę coś bardzo ważnego. Czy ktoś mógłby rozwiać moje wątpliwości?

AKTUALIZACJA (PODSUMOWANIE):

Odpowiedź na moje pytanie „Czy Service Locator jest anty-wzorcem” naprawdę zależy od okoliczności. I zdecydowanie nie sugerowałbym wykreślenia go z listy narzędzi. Może się to okazać bardzo przydatne, gdy zaczniesz zajmować się starszym kodem. Jeśli masz szczęście być na samym początku projektu, podejście DI może być lepszym wyborem, ponieważ ma pewne zalety w porównaniu z lokalizatorem usług.

A oto główne różnice, które przekonały mnie do rezygnacji z usługi Service Locator w nowych projektach:

• Najbardziej oczywiste i najważniejsze: Service Locator ukrywa zależności klas
• Jeśli korzystasz z jakiegoś kontenera IoC, prawdopodobnie przeskanuje on wszystkie konstruktory podczas uruchamiania, aby sprawdzić wszystkie zależności i natychmiast przekaże Ci informacje o brakujących mapowaniach (lub nieprawidłowej konfiguracji); nie jest to możliwe, jeśli używasz kontenera IoC jako lokalizatora usług

Po szczegóły przeczytaj doskonałe odpowiedzi, które podano poniżej.

Jeśli zdefiniujesz wzorce jako anty-wzorce tylko dlatego, że są sytuacje, w których nie pasuje, to TAK jest to anty-wzorce. Ale przy takim rozumowaniu wszystkie wzorce byłyby również anty wzorcami.

Zamiast tego musimy sprawdzić, czy istnieją prawidłowe zastosowania wzorców, a dla Lokalizatora usług istnieje kilka przypadków użycia. Ale zacznijmy od przyjrzenia się przykładom, które podałeś.

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

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

Koszmar konserwacji tej klasy polega na tym, że zależności są ukryte. Jeśli tworzysz i używasz tej klasy:

var myType = new MyType();
myType.MyMethod();

Nie rozumiesz, że ma zależności, jeśli są one ukryte za pomocą lokalizacji usługi. Jeśli zamiast tego użyjemy zastrzyku zależności:

public class MyType
{
    public MyType(IDep1 dep1, IDep2 dep2)
    {
    }

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

        // new dependency
        dep2.DoSomething();
    }
}

Możesz bezpośrednio dostrzec zależności i nie możesz użyć klas przed ich spełnieniem.

Z tego właśnie powodu w typowych zastosowaniach biznesowych należy unikać korzystania z lokalizacji usług. Powinien to być wzorzec do użycia, gdy nie ma innych opcji.

Czy wzór jest anty-wzorem?

Nie.

Na przykład odwrócenie kontenerów kontrolnych nie zadziałałoby bez lokalizacji usługi. W ten sposób wewnętrznie rozwiązują usługi.

Ale znacznie lepszym przykładem są ASP.NET MVC i WebApi. Jak myślisz, co umożliwia wstrzykiwanie zależności w kontrolerach? Zgadza się - lokalizacja serwisu.

Twoje pytania

Ale poczekaj chwilę, gdybyśmy używali podejścia DI, wprowadzilibyśmy w konstruktorze zależność z innym parametrem (w przypadku iniekcji konstruktora). A problem nadal będzie istniał.

Istnieją dwa poważniejsze problemy:

1. Wraz z lokalizacją usługi dodajesz również kolejną zależność: Lokalizator usług.
2. Jak określić, jaki czas życia powinny mieć zależności i jak / kiedy należy je wyczyścić?

Dzięki iniekcji konstruktora przy użyciu kontenera otrzymujesz to za darmo.

Jeśli możemy zapomnieć o skonfigurowaniu ServiceLocator, możemy zapomnieć o dodaniu nowego mapowania w naszym kontenerze IoC, a podejście DI spowodowałoby ten sam problem w czasie wykonywania.

To prawda. Ale dzięki iniekcji konstruktora nie musisz skanować całej klasy, aby dowiedzieć się, których zależności brakuje.

Niektóre lepsze kontenery również sprawdzają wszystkie zależności podczas uruchamiania (skanując wszystkie konstruktory). Tak więc w przypadku tych kontenerów błąd wykonania pojawia się bezpośrednio, a nie w jakimś późniejszym momencie.

Autor wspomniał również o trudnościach z testami jednostkowymi. Ale czy nie będziemy mieli problemów z podejściem DI?

Nie. Ponieważ nie masz zależności od statycznego lokalizatora usług. Czy próbowałeś uzyskać testy równoległe działające z zależnościami statycznymi? To nie jest zabawne.

Chciałbym również zwrócić uwagę, że JEŚLI refaktoryzujesz stary kod, to wzorzec Service Locator nie tylko nie jest anty-wzorcem, ale jest również praktyczną koniecznością. Nikt nigdy nie machnie magiczną różdżką nad milionami linii kodu i nagle cały ten kod będzie gotowy do DI. Więc jeśli chcesz rozpocząć wprowadzanie DI do istniejącej bazy kodu, często jest tak, że będziesz powoli zmieniać rzeczy, aby stały się usługami DI, a kod, który odwołuje się do tych usług, często NIE będzie usługami DI. Dlatego TE usługi będą musiały korzystać z Lokalizatora usług, aby uzyskać wystąpienia tych usług, które ZOSTAŁY przekonwertowane do korzystania z DI.

Dlatego podczas refaktoryzacji dużych starszych aplikacji, aby zaczęły używać koncepcji DI, powiedziałbym, że nie tylko Service Locator NIE jest anty-wzorcem, ale jest to jedyny sposób na stopniowe stosowanie koncepcji DI w bazie kodu.

Z punktu widzenia testów, Service Locator jest zły. Zobacz ładne wyjaśnienie Misko Hevery w Google Tech Talk z przykładami kodu http://youtu.be/RlfLCWKxHJ0 od minuty 8:45. Podobała mi się jego analogia: jeśli potrzebujesz 25 dolarów, poproś bezpośrednio o pieniądze, zamiast oddawać portfel, skąd zostaną pobrane pieniądze. Porównuje również Service Locator ze stogiem siana, który ma potrzebną igłę i wie, jak ją odzyskać. Z tego powodu zajęcia korzystające z Lokalizatora usług są trudne do ponownego wykorzystania.

Problem z konserwacją (który mnie zastanawia)

Istnieją 2 różne powody, dla których korzystanie z lokalizatora usług jest pod tym względem złe.

1. W Twoim przykładzie na stałe wpisujesz statyczne odwołanie do lokalizatora usług w swojej klasie. To ściśle wiąże twoją klasę bezpośrednio z lokalizatorem usług, co z kolei oznacza, że nie będzie ona działać bez lokalizatora usług . Ponadto testy jednostkowe (i każdy, kto używa tej klasy) są również niejawnie zależne od lokalizatora usług. Jedną rzeczą, która wydaje się tutaj niezauważona, jest to, że podczas korzystania z iniekcji konstruktora nie potrzebujesz kontenera DI podczas testowania jednostkowego , co znacznie upraszcza testy jednostkowe (i zdolność programistów do ich zrozumienia). To jest zrealizowana korzyść z testowania jednostkowego, którą można uzyskać dzięki użyciu iniekcji konstruktora.
2. Jeśli chodzi o to, dlaczego konstruktor Intellisense jest ważny, wydaje się, że ludzie tutaj całkowicie przeoczyli sedno. Klasa jest zapisywana raz, ale może być używana w kilku aplikacjach (czyli w kilku konfiguracjach DI) . Z biegiem czasu opłaca się, jeśli spojrzysz na definicję konstruktora, aby zrozumieć zależności klasy, zamiast patrzeć na (miejmy nadzieję, aktualną) dokumentację lub, jeśli to się nie powiedzie, wrócić do oryginalnego kodu źródłowego (co może nie być przydatne), aby określić, jakie są zależności klasy. Zajęcia z lokalizatorem usług są generalnie łatwiejsze do napisania , ale koszt tej wygody kosztuje więcej niż bieżące utrzymanie projektu.

Jasne i proste: klasa z lokalizatorem usług jest trudniejsza do ponownego użycia niż klasa, która akceptuje jej zależności za pośrednictwem swojego konstruktora.

Rozważmy przypadek, w którym musisz skorzystać z usługi, z LibraryAktórej skorzysta jej autor, ServiceLocatorAoraz usługi, od LibraryBktórej autor zdecydował się skorzystać ServiceLocatorB. Nie mamy innego wyjścia, jak tylko użyć 2 różnych lokalizatorów usług w naszym projekcie. Ile zależności trzeba skonfigurować, to gra w zgadywanie, jeśli nie mamy dobrej dokumentacji, kodu źródłowego lub autora szybkiego wybierania. W przypadku braku tych opcji może być konieczne użycie po prostu dekompilatoradowiedzieć się, jakie są zależności. Może być konieczne skonfigurowanie 2 całkowicie różnych interfejsów API lokalizatora usług, aw zależności od projektu może nie być możliwe po prostu opakowanie istniejącego kontenera DI. Współdzielenie jednego wystąpienia zależności między dwiema bibliotekami może w ogóle nie być możliwe. Złożoność projektu może być jeszcze bardziej złożona, jeśli lokalizatory usług nie znajdują się w rzeczywistości w tych samych bibliotekach co usługi, których potrzebujemy - niejawnie przeciągamy dodatkowe odwołania do bibliotek do naszego projektu.

Rozważmy teraz te same dwie usługi wykonane za pomocą iniekcji konstruktora. Dodaj odniesienie do LibraryA. Dodaj odniesienie do LibraryB. Podaj zależności w swojej konfiguracji DI (analizując to, co jest potrzebne za pośrednictwem Intellisense). Gotowe.

Mark Seemann ma odpowiedź StackOverflow, która jasno ilustruje tę korzyść w formie graficznej , która ma zastosowanie nie tylko w przypadku korzystania z lokalizatora usług z innej biblioteki, ale także podczas korzystania z zagranicznych wartości domyślnych w usługach.

Moja wiedza nie jest wystarczająco dobra, aby to ocenić, ale generalnie myślę, że jeśli coś ma zastosowanie w określonej sytuacji, niekoniecznie oznacza to, że nie może być anty-wzorcem. Szczególnie, gdy masz do czynienia z bibliotekami innych firm, nie masz pełnej kontroli nad wszystkimi aspektami i możesz skończyć z użyciem niezbyt najlepszego rozwiązania.

Oto akapit z Adaptive Code via C # :

„Niestety, lokalizator usług jest czasami nieuniknionym anty-wzorcem. W niektórych typach aplikacji - szczególnie Windows Workflow Foundation - infrastruktura nie nadaje się do iniekcji konstruktora. W takich przypadkach jedyną alternatywą jest użycie lokalizatora usług. Jest to lepiej niż w ogóle nie wstrzykiwać zależności. Dla całego mojego witriolu przeciwko wzorowi (anty), jest to nieskończenie lepsze niż ręczne tworzenie zależności. W końcu nadal umożliwia te najważniejsze punkty rozszerzeń zapewniane przez interfejsy, które pozwalają dekoratorom, adapterom, i podobne korzyści ”.

- Hall, Gary McLean. Kod adaptacyjny w języku C #: kodowanie zwinne z wzorcami projektowymi i zasadami SOLID (informacje dla programistów) (s. 309). Edukacja Pearson.

Autor argumentuje, że „kompilator ci nie pomoże” - i to prawda. Kiedy raczysz klasą, będziesz chciał starannie wybrać jej interfejs - między innymi, aby uczynić ją tak niezależną, jak ... na ile ma to sens.

Gdy klient akceptuje odwołanie do usługi (do zależności) za pośrednictwem jawnego interfejsu, Ty

• niejawnie uzyskuje sprawdzanie, więc kompilator „pomaga”.
• Eliminujesz również potrzebę, aby klient wiedział coś o „Lokalizatorze” lub podobnych mechanizmach, dzięki czemu jest bardziej niezależny.

Masz rację, że DI ma swoje problemy / wady, ale wymienione zalety zdecydowanie je przeważają ... IMO. Masz rację, że z DI istnieje zależność wprowadzona w interfejsie (konstruktorze) - ale mam nadzieję, że jest to właśnie ta zależność, której potrzebujesz i którą chcesz, aby była widoczna i możliwa do sprawdzenia.

Tak, lokalizator usług jest anty-wzorcem, narusza hermetyzację i jest solidny .