I stało się. Meta-kontener dependency injection wspomniany przeze mnie na Speaker Idolu na WG.NET zostanie dziś opublikowany na codeplex. Jest to wspólne dzieło moje i Szymona Pobiegi.

     

    Poniżej krótki opis koncepcji, założeń i celów jakie przyświecały nam przy realizacji tego projektu. 

    [opis krótki, bo będę mówił na C2C o koncepcji meta-kontenera i nie chciałbym zepsuć zabawy wszystkim, którzy na C2C się wybierają, a równocześnie czytają artykuły na zine].

     

Założenia i cele:

  1. Chcemy, aby nasze rozwiązania były niezależne od konkretnej implementacji kontenera DI.
  2. Chcemy mieć możliwość podmienienia jednej implementacji kontenera DI na inną.
  3. Chcemy mieć możliwość tworzenia kontenerów potomnych.
  4. Chcemy mieć możliwość rejestrowania:
    1. Komponentów realizujących jakieś usługi.
    2. Metod fabrykujących tworzących komponenty realizujące jakieś usługi.
  5. Chcemy mieć możliwość określenia czasu życia komponentów.
  6. Chcemy aby interfejs meta-kontenera był rozszerzeniem CommonServiceLocatora
  7. Chcemy aby nasze API było jak najprostsze i jak najmniejsze. Wszelkiego rodzaju udogodnienia chcemy zrealizować poprzez metody rozszerzające.

     

Abstrakcja:

    Ogólnie o meta-kontenerze możemy myśleć w kontekście warstwy abstrakcji  nad konkretnymi kontenerami DI. W naszych aplikacjach odwołujemy się jedynie do tego API nie interesując się czy pod spodem jest Unity, Autofac, Ninject czy coś innego.

     

Krótki rzut oka na API:

    I to by było na tyle, jeżeli chodzi o API. Generyczne wersje metody Register dostępne są jako ExtensionMethods.

     

Konsekwencje naszych działań:

  1. Brak wsparcia dla PropertyInjection. Zdecydowaliśmy się na ten krok, gdyż istnieją frameworki, które wymagają w tym kontekście użycia specjalnego atrybutu. Dodatkowo obaj jesteśmy zdania, że należy w jasny sposób wyrażać swoje intencje, a do tego zalecamy ConstructorInjection - tzn. jeżeli jakiś obiekt zależy od pewnych usług, to określmy to wprost przez zależności w konstruktorze.
  2. Nasze API jest minimalistyczne, ale naszym zdaniem do realizacji większości rozwiązań - zupełnie wystarczające. Na chwilę obecną nie ma żadnego wsparcia dla interceptorów, wstrzykiwania zależności do już istniejących obiektów, i pewnie dla wielu innych mechanizmów.
  3. Obsługujemy tylko cykl życia Transient oraz Singleton.

     

    W momencie publikacji projektu zrealizowane są implementacje meta-kontenera na frameworkach:

  4. Unity
  5. Castle.MicroKernel, Castle.Windsor
  6. Autofac

    Wszystkie te implementacje są wersjami referencyjnymi, które mają jedynie pokazać, że na tych frameworkach da się to zrobić. Równocześnie na pewno podejmiemy kroki  mające na celu współpracę z wszystkimi providerami kontenerów DI, którzy wspierają także CommonServiceLocatora.

     

    Tyle z linii frontu na chwilę obecną. Obiecuję, że więcej "mięcha" na temat meta-kontenera pojawi się po C2C, na które wszystkich serdecznie zapraszam.