Jak uniknąć szaleństwa konstruktora Dependency Injection?

Uważam, że moi konstruktorzy zaczynają wyglądać tak:

public MyClass(Container con, SomeClass1 obj1, SomeClass2, obj2.... )

z ciągle rosnącą listą parametrów. Ponieważ „Kontener” jest kontenerem do wstrzykiwania zależności, dlaczego nie mogę tego po prostu zrobić:

public MyClass(Container con)

dla każdej klasy? Jakie są wady? Jeśli to zrobię, wydaje mi się, że używam gloryfikowanego statycznego. Podziel się swoimi przemyśleniami na temat szaleństwa IoC i Dependency Injection.

Masz rację, że jeśli użyjesz kontenera jako Lokalizatora usług, będzie to mniej więcej gloryfikowana fabryka statyczna. Z wielu powodów uważam to za anty-wzór .

Jedną ze wspaniałych zalet wstrzykiwania konstruktora jest to, że łamanie zasady pojedynczej odpowiedzialności jest rażąco oczywiste.

Kiedy tak się stanie, nadszedł czas na refaktoryzację do usług fasadowych . Krótko mówiąc, utwórz nowy, bardziej gruboziarnisty interfejs, który ukrywa interakcję między niektórymi lub wszystkimi drobnoziarnistymi zależnościami, których obecnie potrzebujesz.

Nie sądzę, żeby twoi konstruktorzy klas mieli odniesienia do twojego okresu kontenera IOC. Jest to niepotrzebna zależność między klasą a kontenerem (typ zależności, jakiej IOC próbuje uniknąć!).

Trudność przekazania parametrów nie stanowi problemu. Problem polega na tym, że twoja klasa robi za dużo i powinna być bardziej rozbita.

Wstrzykiwanie zależności może działać jako wczesne ostrzeżenie dla klas, które stają się zbyt duże, szczególnie ze względu na rosnący ból przechodzenia przez wszystkie zależności.

Natknąłem się na podobne pytanie dotyczące wstrzykiwania zależności konstruktorskich i stopnia złożoności wszystkich zależności.

Jednym z podejść, które stosowałem w przeszłości, jest użycie wzoru fasady aplikacji przy użyciu warstwy usługi. To miałoby zgrubne API. Jeśli ta usługa zależy od repozytoriów, użyłaby zastrzyku ustawiającego własności prywatnych. Wymaga to utworzenia abstrakcyjnej fabryki i przeniesienia logiki tworzenia repozytoriów do fabryki.

Szczegółowy kod z wyjaśnieniem można znaleźć tutaj

Najlepsze praktyki dotyczące IoC w złożonej warstwie usług

Przeczytałem cały ten wątek dwa razy i myślę, że ludzie odpowiadają tym, co wiedzą, a nie pytaniem.

Oryginalne pytanie JP wygląda na to, że konstruuje obiekty, wysyłając resolver, a następnie kilka klas, ale zakładamy, że te klasy / obiekty same są usługami, gotowe do wstrzyknięcia. Co jeśli nie są?

JP, jeśli chcesz wykorzystać DI i pragnąć chwały mieszania zastrzyku z danymi kontekstowymi, żaden z tych wzorów (lub rzekomych „anty-wzorów”) nie rozwiązuje tego specjalnie. W rzeczywistości sprowadza się to do użycia pakietu, który wesprze Cię w takim przedsięwzięciu.

Container.GetSevice<MyClass>(someObject1, someObject2)

... ten format jest rzadko obsługiwany. Wierzę, że trudność programowania takiego wsparcia, dodana do nędznej wydajności, która byłaby związana z implementacją, czyni go nieatrakcyjnym dla programistów open source.

Ale należy to zrobić, ponieważ powinienem być w stanie stworzyć i zarejestrować fabrykę dla MyClass, a ta fabryka powinna być w stanie odbierać dane / dane wejściowe, które nie są popychane jako „usługa” tylko ze względu na przekazywanie dane. Jeśli „anty-wzorzec” ma negatywne konsekwencje, wówczas wymuszenie istnienia sztucznych typów usług do przekazywania danych / modeli jest z pewnością negatywne (na równi z przeczuciem, że pakujesz swoje klasy w kontener. Obowiązuje ten sam instynkt).

Istnieją ramy, które mogą pomóc, nawet jeśli wyglądają nieco brzydko. Na przykład Ninject:

Tworzenie instancji za pomocą Ninject z dodatkowymi parametrami w konstruktorze

Dotyczy to .NET, jest popularny i wciąż nie jest tak czysty, jak powinien, ale jestem pewien, że jest coś w jakimkolwiek języku, który wybierzesz.

Wstrzyknięcie pojemnika to skrót, którego ostatecznie będziesz żałować.

Nadmierne wstrzyknięcie nie stanowi problemu, jest zwykle objawem innych wad strukturalnych, w szczególności oddzielenia problemów. To nie jest jeden problem, ale może mieć wiele źródeł, a to, co czyni go tak trudnym do naprawienia, polega na tym, że będziesz musiał poradzić sobie ze wszystkimi, czasami w tym samym czasie (pomyśl o rozplątywaniu spaghetti).

Oto niepełna lista rzeczy, na które należy zwrócić uwagę

Słaby projekt domeny (agregacja katalogu głównego…. Itp.)

Niewłaściwy podział problemów (skład usługi, polecenia, zapytania) Patrz CQRS i pozyskiwanie zdarzeń.

LUB Mapujący (bądź ostrożny, te rzeczy mogą doprowadzić cię do kłopotów)

Zobacz modele i inne DTO (nigdy nie używaj ponownie jednego z nich i staraj się ograniczyć je do minimum !!!!)

Problem:

1) Konstruktor z ciągle rosnącą listą parametrów.

2) Jeśli klasa jest dziedziczona (np .:), RepositoryBasewówczas zmiana sygnatury konstruktora powoduje zmianę klas pochodnych.

Rozwiązanie 1

Przekaż IoC Containerdo konstruktora

Dlaczego

• Nigdy więcej rosnącej listy parametrów
• Podpis Konstruktora staje się prosty

Dlaczego nie

• Sprawia, że ​​klasa jest ściśle sprzężona z pojemnikiem IoC. (To powoduje problemy, gdy 1. chcesz użyć tej klasy w innych projektach, w których używasz innego kontenera IoC. 2. decydujesz się zmienić kontener IoC)
• Sprawia, że ​​twoja klasa jest mniej opisowa. (Naprawdę nie możesz spojrzeć na konstruktora klasy i powiedzieć, czego potrzebuje do działania.)
• Klasa może uzyskać dostęp do potencjalnie wszystkich usług.

Rozwiązanie 2

Utwórz klasę grupującą wszystkie usługi i przekaż ją konstruktorowi

 public abstract class EFRepositoryBase 
 {
    public class Dependency
    {
        public DbContext DbContext { get; }
        public IAuditFactory AuditFactory { get; }

         public Dependency(
            DbContext dbContext,
            IAuditFactory auditFactory)
        {
            DbContext = dbContext;
            AuditFactory = auditFactory;
        }
    }

    protected readonly DbContext DbContext;        
    protected readonly IJobariaAuditFactory auditFactory;

    protected EFRepositoryBase(Dependency dependency)
    {
        DbContext = dependency.DbContext;
        auditFactory= dependency.JobariaAuditFactory;
    }
  }

Klasy pochodnej

  public class ApplicationEfRepository : EFRepositoryBase      
  {
     public new class Dependency : EFRepositoryBase.Dependency
     {
         public IConcreteDependency ConcreteDependency { get; }

         public Dependency(
            DbContext dbContext,
            IAuditFactory auditFactory,
            IConcreteDependency concreteDependency)
        {
            DbContext = dbContext;
            AuditFactory = auditFactory;
            ConcreteDependency = concreteDependency;
        }
     }

      IConcreteDependency _concreteDependency;

      public ApplicationEfRepository(
          Dependency dependency)
          : base(dependency)
      { 
        _concreteDependency = dependency.ConcreteDependency;
      }
   }

Dlaczego

• Dodanie nowej zależności do klasy nie wpływa na klasy pochodne
• Klasa jest agnostyczna dla kontenera IoC
• Klasa ma charakter opisowy (w aspekcie zależności). Zgodnie z konwencją, jeśli chcesz wiedzieć, od której klasy Azależy, informacje te są gromadzoneA.Dependency
• Podpis konstruktora staje się prosty

Dlaczego nie

• trzeba utworzyć dodatkową klasę
• rejestracja usługi staje się złożona (musisz zarejestrować się X.Dependencyosobno)
• Koncepcyjnie to samo co przekazywanie IoC Container
• ..

Rozwiązanie 2 jest jednak surowe, jeśli istnieje przeciwko temu solidny argument, doceniony zostanie komentarz opisowy

To podejście, którego używam

public class Hero
{

    [Inject]
    private IInventory Inventory { get; set; }

    [Inject]
    private IArmour Armour { get; set; }

    [Inject]
    protected IWeapon Weapon { get; set; }

    [Inject]
    private IAction Jump { get; set; }

    [Inject]
    private IInstanceProvider InstanceProvider { get; set; }


}

Oto przybliżone podejście do wykonywania wstrzyknięć i uruchamiania konstruktora po wstrzyknięciu wartości. To jest w pełni funkcjonalny program.

public class InjectAttribute : Attribute
{

}


public class TestClass
{
    [Inject]
    private SomeDependency sd { get; set; }

    public TestClass()
    {
        Console.WriteLine("ctor");
        Console.WriteLine(sd);
    }
}

public class SomeDependency
{

}


class Program
{
    static void Main(string[] args)
    {
        object tc = FormatterServices.GetUninitializedObject(typeof(TestClass));

        // Get all properties with inject tag
        List<PropertyInfo> pi = typeof(TestClass)
            .GetProperties(BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.Public)
            .Where(info => info.GetCustomAttributes(typeof(InjectAttribute), false).Length > 0).ToList();

        // We now happen to know there's only one dependency so we take a shortcut just for the sake of this example and just set value to it without inspecting it
        pi[0].SetValue(tc, new SomeDependency(), null);


        // Find the right constructor and Invoke it. 
        ConstructorInfo ci = typeof(TestClass).GetConstructors()[0];
        ci.Invoke(tc, null);

    }
}

Obecnie pracuję nad projektem hobby, który działa tak: https://github.com/Jokine/ToolProject/tree/Core

Jakiego systemu wstrzykiwania zależności używasz? Czy zamiast tego próbowałeś zastosować zastrzyk na bazie setera?

Zaletą wstrzykiwania opartego na konstruktorach jest to, że wygląda naturalnie dla programistów Java, którzy nie używają frameworków DI. Potrzebujesz 5 rzeczy do zainicjowania klasy, a następnie masz 5 argumentów dla swojego konstruktora. Minusem jest to, co zauważyłeś, staje się niewygodne, gdy masz wiele zależności.

Za pomocą Springa możesz przekazać wymagane wartości ustawieniom i możesz użyć @required adnotacji, aby wymusić ich wstrzyknięcie. Minusem jest to, że musisz przenieść kod inicjujący z konstruktora na inną metodę i mieć wywołanie Spring, które po wstrzyknięciu wszystkich zależności poprzez oznaczenie go @PostConstruct. Nie jestem pewien co do innych frameworków, ale zakładam, że robią coś podobnego.

Oba sposoby działają, to kwestia preferencji.