W ten sposób piszę ten kod, który można przetestować, ale czy coś jest z nim nie tak?

Mam interfejs o nazwie IContext. W tym celu tak naprawdę nie ma znaczenia, co robi, oprócz następujących czynności:

T GetService<T>();

Metoda ta polega na sprawdzeniu bieżącego kontenera DI aplikacji i próbie rozwiązania zależności. Myślę, że dość standardowy.

W mojej aplikacji ASP.NET MVC mój konstruktor wygląda tak.

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

Więc zamiast dodawania wielu parametrów konstruktora dla każdej usługi (bo to będzie naprawdę denerwujące i czasochłonne dla programistów Rozszerzenie stosowania) Używam tej metody, aby uzyskać usług.

Teraz jest źle . Jednak w tej chwili usprawiedliwiam to w mojej głowie - mogę to wyśmiewać .

Mogę. IContextTestowanie kontrolera nie będzie trudne . W każdym razie musiałbym:

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

        // etc etc
    }
}

Ale jak powiedziałem, wydaje się to złe. Wszelkie myśli / nadużycia są mile widziane.

Posiadanie jednego zamiast wielu parametrów w konstruktorze nie jest problematyczną częścią tego projektu . Tak długo, jak twoja IContextklasa jest niczym innym, jak tylko fasada usługi , szczególnie w celu zapewnienia zależności używanych w MyControllerBasecałym kodzie, a nie ogólny lokalizator usług używany w całym kodzie, ta część twojego kodu jest w porządku.

Twój pierwszy przykład może zostać zmieniony na

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

nie byłaby to znacząca zmiana projektu MyControllerBase. To, czy ten projekt jest dobry czy zły, zależy tylko od tego, czy chcesz

• upewnij się TheContext, SomeServicei AnotherServicezawsze wszystko zainicjowany z makiety obiektów, lub wszystkie z nich z rzeczywistych obiektów
• lub, aby umożliwić ich inicjalizację przy użyciu różnych kombinacji 3 obiektów (co oznacza, że ​​w tym przypadku musisz przekazać parametry indywidualnie)

Zatem użycie tylko jednego parametru zamiast 3 w konstruktorze może być w pełni uzasadnione.

Problemem jest publiczne IContextujawnienie GetServicemetody. IMHO powinieneś tego unikać, zamiast tego trzymaj się wyraźnie „metod fabrycznych”. Więc czy będzie w porządku zaimplementować metody GetSomeServicei GetAnotherServicez mojego przykładu za pomocą lokalizatora usług? IMHO to zależy. Tak długo, jak długo IContextklasa będzie po prostu tworzyła prostą abstrakcyjną fabrykę, której celem jest dostarczenie jawnej listy obiektów usług, co jest IMHO dopuszczalne. Fabryki abstrakcyjne to zazwyczaj tylko „klej” kod, który sam nie musi być testowany jednostkowo. Niemniej jednak powinieneś zadać sobie pytanie, czy w kontekście metod takich jak GetSomeService, czy naprawdę potrzebujesz lokalizatora usług, czy też jawne wywołanie konstruktora nie byłoby prostsze.

Uważajcie więc, kiedy trzymacie się projektu, w którym IContextimplementacja jest po prostu owinięciem publicznej, ogólnej GetServicemetody, pozwalającej rozwiązać dowolne zależności przez arbitralne klasy, wtedy wszystko stosuje się tak, jak napisał @BenjaminHodgson w swojej odpowiedzi.

Ten projekt jest znany jako Service Locator * i nie podoba mi się. Istnieje wiele argumentów przeciwko niemu:

Lokalizator usług łączy Cię z Twoim kontenerem . Używając regularnego wstrzykiwania zależności (gdy konstruktor wyraźnie określa zależności), możesz od razu zastąpić swój kontener innym lub powrócić do newwyrażeń. Z twoim IContexttak naprawdę nie jest to możliwe.

Lokalizator usług ukrywa zależności . Jako klient bardzo trudno jest powiedzieć, czego potrzebujesz, aby zbudować instancję klasy. Potrzebujesz jakiegoś rodzaju IContext, ale musisz także ustawić kontekst, aby zwrócić poprawne obiekty w celu wykonania MyControllerBasepracy. Nie jest to wcale oczywiste z podpisu konstruktora. Dzięki zwykłemu DI kompilator mówi dokładnie to, czego potrzebujesz. Jeśli twoja klasa ma wiele zależności, powinieneś poczuć ten ból, ponieważ skłoni cię to do refaktoryzacji. Lokalizator usług ukrywa problemy ze złymi projektami.

Lokalizator usług powoduje błędy w czasie wykonywania . Jeśli zadzwonisz GetServicez parametrem złego typu, otrzymasz wyjątek. Innymi słowy, twoja GetServicefunkcja nie jest funkcją całkowitą. (Funkcje całkowite są pomysłem ze świata FP, ale w zasadzie oznacza to, że funkcje zawsze powinny zwracać wartość.) Lepiej pozwolić kompilatorowi pomóc i powiedzieć, kiedy pomyliłeś zależności.

Lokalizator usług narusza zasadę substytucji Liskowa . Ponieważ jego zachowanie różni się w zależności od argumentu typu, Service Locator może być postrzegany tak, jakby efektywnie dysponował nieskończoną liczbą metod w interfejsie! Ten argument został szczegółowo opisany tutaj .

Lokalizator usług jest trudny do przetestowania . Podałeś przykład podróbki IContextdo testów, co jest w porządku, ale na pewno lepiej nie pisać tego kodu w pierwszej kolejności. Po prostu wstrzyknij swoje fałszywe zależności bezpośrednio, bez przechodzenia przez lokalizator usług.

Krótko mówiąc, po prostu nie rób tego . Wydaje się, że to uwodzicielskie rozwiązanie problemu klas z wieloma zależnościami, ale na dłuższą metę po prostu sprawisz, że twoje życie będzie nieszczęśliwe.

_{* Definiuję Service Locator jako obiekt za pomocą ogólnej Resolve<T>metody, która jest w stanie rozwiązać dowolne zależności i jest używana w całej bazie kodu (nie tylko w katalogu głównym). Nie jest to to samo, co Service Facade (obiekt, który łączy jakiś niewielki znany zestaw zależności) lub Abstract Factory (obiekt, który tworzy instancje jednego typu - typ Abstract Factory może być ogólny, ale metoda nie jest) .}

Najlepsze argumenty przeciwko anty-wzorcowi Service Locator są wyraźnie stwierdzone przez Marka Seemanna, więc nie będę się zbytnio zastanawiał, dlaczego to zły pomysł - jest to podróż edukacyjna, którą musisz poświęcić trochę czasu na zrozumienie siebie (I również polecam książkę Marka ).

OK, aby odpowiedzieć na pytanie - ponownie określmy swój rzeczywisty problem :

Zamiast dodawać wiele konstruktorów dla każdej usługi (ponieważ będzie to naprawdę denerwujące i czasochłonne dla programistów rozszerzających aplikację) używam tej metody, aby uzyskać usługi.

Istnieje pytanie, które rozwiązuje ten problem na StackOverflow . Jak wspomniano w jednym z komentarzy:

Najlepsza uwaga: „Jedną ze wspaniałych korzyści płynących z iniekcji konstruktora jest to, że łamanie zasady pojedynczej odpowiedzialności jest rażąco oczywiste”.

Szukasz niewłaściwego miejsca na rozwiązanie swojego problemu. Ważne jest, aby wiedzieć, kiedy klasa robi zbyt wiele. W twoim przypadku mocno podejrzewam, że nie ma potrzeby stosowania „kontrolera podstawowego”. W rzeczywistości w OOP prawie zawsze nie ma potrzeby dziedziczenia . Różnice w zachowaniu i współdzielonej funkcjonalności można osiągnąć całkowicie poprzez odpowiednie użycie interfejsów, co zwykle skutkuje lepiej faktoryzowanym i enkapsulowanym kodem - i nie ma potrzeby przekazywania zależności konstruktorom nadklasy.

We wszystkich projektach, nad którymi pracowałem, w których istnieje Kontroler bazowy, zostało to zrobione wyłącznie w celu udostępnienia dogodnych właściwości i metod, takich jak IsUserLoggedIn()i GetCurrentUserId(). STOP . To jest okropne niewłaściwe wykorzystanie dziedzictwa. Zamiast tego utwórz komponent, który udostępnia te metody i weź zależność od niego tam, gdzie jest potrzebny. W ten sposób komponenty pozostaną testowalne, a ich zależności będą oczywiste.

Oprócz czegokolwiek innego, używając wzorca MVC, zawsze zalecałbym chudych kontrolerów . Możesz przeczytać więcej na ten temat tutaj, ale istota wzorca jest prosta, że ​​kontrolery w MVC powinny robić tylko jedno: obsłużyć argumenty przekazane przez środowisko MVC, delegując inne obawy na inny komponent. To znowu jest zasada pojedynczej odpowiedzialności w pracy.

Naprawdę pomocna byłaby znajomość twojego przypadku użycia, aby dokonać dokładniejszej oceny, ale szczerze mówiąc, nie mogę wymyślić żadnego scenariusza, w którym klasa podstawowa byłaby lepsza niż dobrze uwzględnione zależności.

Dodaję do tego odpowiedź na podstawie wkładu wszystkich innych. Wielkie dzięki wszystkim. Najpierw moja odpowiedź: „Nie, nie ma w tym nic złego”.

Odpowiedź doktora Browna na „Service Facade” Przyjąłem tę odpowiedź, ponieważ to, czego szukałem (jeśli odpowiedź brzmiała „nie”), to kilka przykładów lub rozwinięcie tego, co robiłem. Podał to, sugerując, że A) ma nazwę, a B) są prawdopodobnie lepsze sposoby na zrobienie tego.

Odpowiedź Benjamina Hodgsona na „Lokalizator usług” Mimo, że doceniam wiedzę, którą tutaj zdobyłem, to nie jestem „lokalizatorem usług”. Jest to „fasada usług”. Wszystko w tej odpowiedzi jest poprawne, ale nie w moich okolicznościach.

Odpowiedzi USR

Zajmę się tym bardziej szczegółowo:

W ten sposób rezygnujesz z wielu statycznych informacji. Odradzasz podejmowanie decyzji dotyczących środowiska wykonawczego, tak jak robi to wiele języków dynamicznych. W ten sposób tracisz weryfikację statyczną (bezpieczeństwo), obsługę dokumentacji i narzędzi (autouzupełnianie, refaktoryzacje, znajdowanie zastosowań, przepływ danych).

Nie tracę żadnego oprzyrządowania i nie tracę żadnego „statycznego” pisania. Fasada usługi zwróci to, co skonfigurowałem w moim kontenerze DI lub default(T). A to, co zwraca, jest „wpisywane”. Odbicie jest zamknięte.

Nie rozumiem, dlaczego dodanie dodatkowych usług jako argumentów konstruktora jest dużym obciążeniem.

Z pewnością nie jest to „rzadkie”. Ponieważ używam kontrolera podstawowego , za każdym razem, gdy muszę zmienić jego konstruktor, być może będę musiał zmienić 10, 100, 1000 innych kontrolerów.

Jeśli użyjesz struktury wstrzykiwania zależności, nie będziesz musiał nawet ręcznie przekazywać wartości parametrów. Z drugiej strony tracisz statyczne zalety, ale nie tak wiele.

Używam zastrzyku zależności. O to chodzi.

I na koniec, komentarz Julesa do odpowiedzi Benjamina nie tracę żadnej elastyczności. To moja fasada usług. Mogę dodać tyle parametrów, GetService<T>ile chcę, aby rozróżnić różne implementacje, tak jak zrobiłby to podczas konfigurowania kontenera DI. Na przykład mógłbym zmienić, GetService<T>()aby GetService<T>(string extraInfo = null)obejść ten „potencjalny problem”.

W każdym razie jeszcze raz dziękuję wszystkim. To było naprawdę przydatne. Twoje zdrowie.