Patrzyłem na Common Service Locator jako sposób na abstrakcję mojego kontenera IoC, ale zauważyłem, że niektórzy ludzie są zdecydowanie przeciwko temu typowi.Kiedy należy korzystać ze wspólnego lokalizatora usług?
Czy ludzie zalecają, aby nigdy go nie używać? Zawsze go używasz? czy czasem go używasz? Jeśli czasami, to w jakich sytuacjach byś go używał i jakich sytuacji byś go nie używał.
Wyobraź sobie, że piszesz kod biblioteki, który ma być używany przez zewnętrznych programistów. Twój kod musi umożliwiać tworzenie obiektów usług, które zapewniają ci programiści. Jednak nie wiesz, który kontener IoC będzie używał każdy z Twoich rozmówców.
Usługa Common Service Locator pozwala poradzić sobie z powyższym bez wymuszania danego IoC na użytkownikach.
W samej bibliotece możesz chcieć zarejestrować własne zajęcia w IoC, teraz jest o wiele trudniej, ponieważ musisz wybrać IoC na własny użytek, który nie przeszkodzi twoim rozmówcom.
Dodam tylko, że możesz być zmuszony do korzystania z CSL również wtedy, gdy po prostu nie masz wspólnego katalogu Composition Root lub jest on poza twoją kontrolą. Przykładem może być niestandardowy walidator certyfikatów w usłudze WCF. –
Ostatnio czytałem o koncepcji lokalizatora usług. Jest to sposób na zmniejszenie sprzężenia, ale wymaga połączenia kodu z lokalizatorem - nie pojemnika wspierającego lokalizator, ale samego lokalizatora. Jest to kompromis, ale może być korzystne w odpowiedniej sytuacji.
Jedna z sytuacji, w której może być pomocna, gdy masz kod, który nie korzysta z DI, taki jak dotychczasowy kod - Jestem teraz na tej łodzi. Wciąganie wymaganych obiektów przez SL, zamiast bezpośrednio je tworzyć, pozwala na dodanie jakiejś abstrakcji. Uważam to za pośredni krok pomiędzy SL a DI/IoC.
W przypadku starszego kodu może nie być możliwe użycie wstrzyknięcia konstruktora, właściwsze może być wtedy wprowadzenie właściwości. –
W bibliotece Common Service Locator nie chodzi tylko o wzór Service Locator, jak starałem się wyjaśnić w mojej odpowiedzi. – Steven
Zauważyłem, że jeden z argumentów przeciwko używaniu CSL jest fałszywy, ponieważ deweloperzy uważają, że ta biblioteka jest w stanie wykonać tylko wzór Service Locator. Tak jednak nie jest, ponieważ jest również łatwy w użyciu ze wzorem Dependency Injection.
Jednak biblioteka CSL została specjalnie zaprojektowana dla projektantów frameworków, którzy muszą zezwalać użytkownikom na rejestrowanie zależności. Ponieważ biblioteka będzie wywoływała CSL bezpośrednio, z perspektywy ramowej mówimy o wzorze SL, stąd jego nazwa.
Jednak jako projektant frameworków uzależnienie od CSL nie powinno być lekceważące. Dla użyteczności twojej struktury zwykle lepiej jest mieć swój własny mechanizm DI. Bardzo powszechnym mechanizmem jest konfigurowanie zależności w pliku konfiguracyjnym. Ten wzorzec jest używany w całej strukturze .NET. Niemal każda zależność może być zastąpiona inną. Wzorzec dostawcy .NET jest zbudowany na tym.
Kiedy, jako projektant frameworków, będziesz zależny od CSL, użytkownicy będą trudniej z niego korzystać. Użytkownicy będą musieli skonfigurować kontener IoC i podłączyć go do CSL. Jednak nie jest możliwe, aby framework sprawdzał konfigurację, co można zrobić podczas korzystania z systemu konfiguracyjnego .NET, który obsługuje wszystkie rodzaje sprawdzania poprawności.
+1 - jest to jedyna wnikliwa odpowiedź tutaj. – MattDavey
Jeśli masz kod biblioteki, który potrzebuje usług i ten kod mógłby być hostowany w kontekście większego frameworka/środowiska wykonawczego, wówczas framework/runtime musiałby zapewnić mechanizm, w którym możesz uruchomić niestandardowy kod przy starcie w którym możesz zainicjalizować swój kontener i zarejestrować zależności. Dobrym przykładem miejsca, w którym może występować problem z CSL, jest używanie go w kontekście MSCRM. Możesz mieć niestandardową logikę biznesową wykonywaną przez rejestrowanie wtyczek, które wykonuje szkielet MSCRM w określonych zdarzeniach. Problem, który napotkasz, to miejsce, w którym uruchamiasz logikę rejestracji, ponieważ nie ma żadnego zdarzenia "startowego", które możesz zasubskrybować podczas konfigurowania swojego kontenera DI.Nawet gdybyś mógł w jakiś sposób skonfigurować DI, musiałbyś umieścić biblioteki CSL i DI w GAC, ponieważ jest to jedyny sposób na wywołanie kodu zewnętrznego z wtyczki (jeszcze jeden element do dodania do listy kontrolnej wdrażania). W scenariuszach takich jak ten lepiej jest mieć swoje zależności jako parametry konstruktora, które kod wywołujący może zainicjować zgodnie z jego potrzebami (poprzez iniektor konstruktora lub ręcznie "nowszy" do odpowiedniej implementacji interfejsu).
Szukasz scenariuszy użycia dla Common Service Locator specjalnie lub bardziej ogólnie dla wzorca lokalizatora usług? Terminy niekoniecznie są zamienne ... – MattDavey