Śledziłem serię Daniel Cazzulino's o numerze building a DI container using TDD. W wersji part five of the series dodaje obsługę hierarchii kontenerów bez komentowania, co czyni tę funkcję przydatną. W wielu frameworkach DI widziałem wzmiankę o wsparciu dla hierarchii, ale mam problemy ze zrozumieniem, kiedy zostaną użyte i dlaczego. Czy ktoś może zaoferować wgląd?Dlaczego struktury Dependency Injection obsługują hierarchie kontenerów?
Here's a sample używa kontenerów dla dzieci w scenariuszu podobnym do opisanego przez Matta. Używa kontenerów podrzędnych do wybierania między różnymi konfiguracjami bazy danych.
Kluczem tutaj jest to, że większość konfiguracji jest dzielony pomiędzy pojemnikami dzieci (to wspólna część należy w kontenerze nadrzędnym)
Zostawiłem komentarz na blogu kzu zadającym to samo pytanie. Szkoda, że nie sprecyzował przypadku użycia takiej funkcji przed jej zakodowaniem.
Jedyne, co mogłem wymyślić, to to, czy chcesz, aby różne typy zostały rozwiązane z kontenera w różnych częściach aplikacji. Na przykład, jeśli posiadasz system wprowadzania zamówień z dwiema oddzielnymi sekcjami, a każda sekcja jest identyczna, z wyjątkiem tego, że muszą one przedstawiać inną listę produktów, możesz utworzyć kontener dla dzieci dla każdej sekcji i "zastąpić" rejestrację swojego repozytorium produktu w każdym. Za każdym razem, gdy sekcja próbowała rozwiązać repozytorium produktu (lub cokolwiek zależnego od jednego), otrzymywałaby instancję skonfigurowaną w kontenerze podrzędnym, a nie nadrzędną. Trochę jak nadpisanie wirtualnej metody.
To może być daleko poza bazą, ale jest to najlepsze, co mogę wymyślić.
Jest dobry powód do posiadania pojemników dziecka, jeżeli zależność wtrysku jest w pełni objęte projektem . Wyobraźmy sobie aplikację, która przetwarza wiadomości z dwóch różnych, ale podobnych systemów. Większość przetwarzania jest podobna, ale istnieją odmiany do obsługi zgodności z tymi systemami. Naszym celem jest ponowne wykorzystanie kodu, który możemy, pisząc inny kod, ponieważ wymagania różnią się.
W programowaniu OO łączymy ze sobą serię klas, które współpracują w celu spełnienia wymagań systemowych. Pojemnik DI bierze na siebie tę odpowiedzialność. Kiedy wiadomość przychodzi z systemu, chcemy zbudować zestaw współpracujących klas, odpowiednich do przetwarzania wiadomości z tego konkretnego systemu.
Mamy pojemnik najwyższego poziomu, który zawiera przedmioty, które nie różnią się między dwoma systemami. Następnie mamy kontenery dla dzieci, które są różne dla różnych systemów. Kiedy nadejdzie wiadomość, prosimy o podanie odpowiedniego kontenera DI dla dziecka o numerze messageProcessor. W oparciu o konfigurację tego kontenera (w razie potrzeby odwołanie do kontenera nadrzędnego) struktura DI może zwrócić komunikat messageProcessor (będący obiektem wspieranym przez odpowiednich współpracowników) dla danego systemu.
Proszę zostaw komentarz, jeśli nie jest to jednoznaczna odpowiedź. Możesz również wyszukać "problem z nogami robotów". Każda noga jest identyczna, ale jedna potrzebuje lewej stopy, a druga potrzebuje prawej stopy. Możemy mieć dziecięcy pojemnik DI dla każdej nogi.
Najlepszym przykładem, jaki mam na temat zagnieżdżonych kontenerów, jest system okienkowy. Bardzo proste jest oddzielenie spraw, aby każda karta/okno miała swój własny kontener niezależny od innych kart/okien, a wszystkie kontenery okien dziedziczą globalne zależności z kontenera nadrzędnego.
Jest to szczególnie potrzebne, jeśli możesz mieć zduplikowane karty/okna, ponieważ w wielu przypadkach chcesz odróżnić wystąpienia różnych klas dla każdej zduplikowanej zakładki/okna