Dependency Inject (DI) "friendly" library

Termin "dependency injection" nie ma w ogóle nic wspólnego z kontenerem IoC, mimo że często widuje się je razem wymienione. Oznacza to po prostu, że zamiast pisać swój kod w ten sposób:

public class Service
{
    public Service()
    {
    }

    public void DoSomething()
    {
        SqlConnection connection = new SqlConnection("some connection string");
        WindowsIdentity identity = WindowsIdentity.GetCurrent();
        // Do something with connection and identity variables
    }
}

Piszesz to tak:

public class Service
{
    public Service(IDbConnection connection, IIdentity identity)
    {
        this.Connection = connection;
        this.Identity = identity;
    }

    public void DoSomething()
    {
        // Do something with Connection and Identity properties
    }

    protected IDbConnection Connection { get; private set; }
    protected IIdentity Identity { get; private set; }
}

Oznacza to, że pisząc swój kod robisz dwie rzeczy:

1. Polegaj na interfejsach zamiast na klasach, gdy uważasz, że implementacja może wymagać zmieniony;

2. Zamiast tworzyć instancje tych interfejsów wewnątrz klasy, przekazuj je jako argumenty konstruktora (alternatywnie mogą być przypisane do właściwości publicznych; pierwszy to constructor injection, drugi to property injection ).

Nic z tego nie zakłada istnienia żadnej biblioteki DI, a to nie sprawia, że kod jest trudniejszy do napisania bez niej.

Jeśli szukasz przykładu z tego, nie patrzeć dalej niż sam. NET Framework:

• List<T> implementuje IList<T>. Jeśli zaprojektujesz swoją klasę tak, aby używała IList<T> (lub IEnumerable<T>), możesz skorzystać z pojęć takich jak lazy-loading, jak Linq do SQL, Linq do encji i NHibernate, które robią za kulisami, zwykle poprzez wtrysk właściwości. Niektóre klasy frameworku faktycznie akceptują IList<T> jako argument konstruktora, na przykład BindingList<T>, który jest używany dla kilku funkcji wiązania danych.

• Linq do SQL i EF są zbudowane w całości wokół IDbConnection i powiązanych interfejsów, które mogą być przekazywane przez publiczne konstruktory. Nie musisz ich jednak używać; domyślne konstruktory działają dobrze z łańcuchem połączeń znajdującym się gdzieś w pliku konfiguracyjnym.

• Jeśli kiedykolwiek pracujesz nad komponentami WinForms, masz do czynienia z "usługami", takimi jak INameCreationService lub IExtenderProviderService. Nawet nie wiesz, co to są konkretne klasy . . NET faktycznie ma swój własny kontener IoC, IContainer, który jest używany do tego celu, a klasa Component ma metodę GetService, która jest faktycznym lokalizatorem usług. Oczywiście nic nie stoi na przeszkodzie, aby używać dowolnego lub wszystkich tych interfejsów bez IContainer lub tego konkretnego lokalizatora. Same usługi są tylko luźno połączone z kontenerem.

• Kontrakty w WCF są zbudowane w całości wokół interfejsów. Rzeczywista konkretna klasa usług jest zwykle określana nazwą w pliku konfiguracyjnym, który jest zasadniczo DI. Wiele osób nie zdaje sobie z tego sprawy, ale jest całkowicie możliwe Zamiana tego systemu konfiguracyjnego na inny kontener IoC. Co ciekawsze, zachowania serwisowe są przykładami IServiceBehavior, które można dodać później. Ponownie, możesz łatwo podłączyć to do kontenera IoC I poprosić go o wybranie odpowiednich zachowań, ale funkcja jest całkowicie użyteczna bez niego.

I tak dalej i tak dalej. DI znajdziesz wszędzie w. NET, chodzi o to, że normalnie robi się to tak bezproblemowo, że nawet nie myślisz o tym jak o DI.

Jeśli chcesz zaprojektować bibliotekę z obsługą DI dla maksymalnej użyteczności, najlepszą propozycją jest prawdopodobnie dostarczenie własnej domyślnej implementacji IoC przy użyciu lekkiego kontenera. IContainer jest świetnym wyborem, ponieważ jest częścią samego. NET Framework.

EDIT 2015: Czas minął, teraz zdaję sobie sprawę, że to wszystko było wielkim błędem. Pojemniki IoC są okropne, a DI jest bardzo słabym sposobem radzenia sobie ze skutkami ubocznymi. Skutecznie, wszystkie odpowiedzi tutaj (i samo pytanie) należy unikać. Po prostu bądź świadomy efektów ubocznych, oddziel je od czystego kodu, a Wszystko inne albo wpadnie na swoje miejsce, albo będzie nieistotne i zbędne.

Oryginalna odpowiedź:

I had to face this same decyzja przy opracowywaniu SolrNet . Zacząłem od tego, by być przyjaznym dla DI i nie wymagającym kontenerów, ale gdy dodałem coraz więcej wewnętrznych komponentów, wewnętrzne fabryki szybko stały się nie do zarządzania, a powstała Biblioteka była nieelastyczna.

Zakończyłem pisanie własnego bardzo prostego wbudowanego kontenera IoC, zapewniając jednocześnie Windsor facilityi Ninject module. Integracja biblioteki z innymi kontenerami to tylko kwestia prawidłowo okablowane komponenty, żebym mógł łatwo zintegrować je z Autofac, Unity, StructureMap, cokolwiek.

Więcej szczegółów w tym blogu .

MassTransit wydaje się polegać na czymś podobne. Posiada interfejs iobjectbuilder , który jest tak naprawdę Iservicelocator CommonServiceLocator z kilkoma innymi metodami, a następnie implementuje to dla każdego kontenera, tj. NinjectObjectBuilder i zwykły moduł/obiekt, tj. MassTransitModule. Następnie opiera się na IObjectBuilder, aby utworzyć instancję tego, czego potrzebuje. Jest to oczywiście poprawne podejście, ale osobiście nie podoba mi się to bardzo, ponieważ w rzeczywistości również przechodzi wokół kontenera much, używając go jako lokalizatora usług.

MonoRail implementuje swój własny kontener , który implementuje stary, dobry IServiceProvider . Ten kontener jest używany w tym frameworku za pośrednictwem interfejsu, który udostępnia dobrze znane Usługi . Aby uzyskać betonowy pojemnik, ma wbudowany lokalizator dostawcy usług . W związku z tym, że nie jest to możliwe, nie jest to konieczne, ponieważ nie jest to konieczne. dostawca.

Podsumowując: nie ma idealnego rozwiązania. Podobnie jak w przypadku każdej decyzji projektowej, kwestia ta wymaga równowagi między elastycznością, konserwacją i wygodą.

To, co chciałbym zrobić, to zaprojektować moją bibliotekę w sposób di container agnostyczny, aby ograniczyć zależność od kontenera w jak największym stopniu. Pozwala to na zamianę kontenera DI na inny, jeśli zajdzie taka potrzeba.

Następnie udostępnij warstwę nad logiką DI użytkownikom biblioteki, aby mogli korzystać z dowolnego frameworka wybranego przez interfejs. W ten sposób mogą nadal korzystać z funkcjonalności DI, które zostały ujawnione i mogą swobodnie korzystać z dowolnego innego frameworka dla swoich własnych cele.

Pozwolenie użytkownikom biblioteki na podłączenie własnego frameworka DI wydaje mi się nieco złe, ponieważ znacznie zwiększa ilość konserwacji. To również staje się bardziej środowiskiem wtyczek niż prostym DI.