Mechanizm wiązania iniekcji automatycznej

Question

Dwa powszechne mechanizmy tworzenia powiązań iniekcji zależności, na przykład przez kontener IOC, pochodzą z konfiguracji XML lub bloku imperatywnego kodu. W takich przypadkach kluczowa para wartości jest jawna (tzn. Key = requested type, value = return type).

Nadal istnieje trzecia metoda "heurystyczna", w której kontener aplikacji/IOC ma tylko klucze [IMyClass], a następnie kontener odzwierciedla zestaw zależności w zależności od złożenia aplikacji, aby znaleźć wszystkie dopasowane do nazwy klasy betonu [MyClass] . Mówiąc inaczej, wartości "zwracanego typu" są odkrywane, a nie deklarowane.

Co chciałbym wiedzieć, jest dwojaki:

1. Które pojemniki MKOl (lub inne narzędzia późne wiążących) umożliwienia heurystycznego podejścia? Czy to podejście ma bardziej powszechną nazwę?
2. Czy są inne techniki wiążące oprócz trzech wymienionych na liście, które są używane w praktyce?

Answer 1

To się nazywa Konwencja oparte Konfiguracja lub Auto rejestracji i jest obsługiwane przez nich.NET DI Kontenery:

• Castle Windsor
• StructureMap
• Autofac

Najczęstsze mechanizmy służące do konfiguracji DI pojemniki są

• XML
• kod jak konfiguracja
• Konwencja oparte Konfiguracja

Czwarty, ale niezbyt często, podejściem jest użycie atrybutów. Managed Extensibility Framework jest najbardziej widocznym przykładem tego podejścia, które jest bardziej powszechne w Javie.

Answer 2

Zwykle robiłem to, co określasz jako niestandardowy krok w konwergencji. AFAIK nie ma kontenera dostarczającego po wyjęciu z pudełka takiej strategii (i moim zdaniem nie jest to część kontenerowa, ale konfiguracja rzeczy, która powinna być zewnętrzna od odpowiedzialności kontenera).

Answer 3

To, co nazywacie podejściem "heurystycznym", nazywam konwencjami. Większość kontenerów IoC umożliwia zastąpienie sposobu rozwiązywania powiązań, co oznacza, że ​​można wprowadzić dowolną konwencję. Nie ma takich domyślnych konwencji, które znam. Przeciwnie, większość kontenerów nie robi nic, co domyślnie; Twoim zadaniem jest powiedzenie im, jak rozwiązywać typy, poprzez plik konfiguracyjny lub kod.

Przykład znalezionej konwencji niestandardowej jest dość powszechny, co pozwala zaoszczędzić wiele deklaracji: Jeśli żądanym typem jest typ interfejsu zaczynający się od "I", a kończący się na "Usługa", to należy spróbować utworzyć i rozwiązać typ o tej samej nazwie oprócz "ja". Spowoduje to automatyczną zmianę nazw takich jak IFooService na FooService. Ponadto można łatwo wprowadzić logikę, aby decydować o różnych usługach w różnych kontekstach, a użytkownik może obsługiwać okresy istnienia usługi we wspólnym miejscu.

Ponieważ można zastąpić, jak większość kontenerów IoC wiązać można wprowadzać inne zachowania, jak również. Generalnie jednak są naprawdę dwie opcje:

1. Konfigurowanie w czasie wykonywania (poprzez pliki konfiguracyjne, takie jak pliki XML)
2. skonfigurować co kompilacji (za pomocą deklaratywnej DSL-like API lub poprzez zwyczaju konwencje lub inna forma niestandardowej logiki)

Answer 4

Odkąd stosowane StructureMap trochę bym wiedzieć, jak zrobić coś takiego z tego kontenera: To w zasadzie być Konwencja klienta Rejestracja (z inicjalizacji lub Registry, przejdź do bloku Scan-lambda i znajdź metodę "Convention").

To pozwala spojrzeć na odbitych typów, a następnie wstawić je do konfiguracji pojemnika, jak widać pasuje. Powinno to pozwolić na to, co próbujesz zrobić.