Pure.DI nächster Schritt

Kürzlich wurden Sie in diesem Beitrag in die Pure.DI- Bibliothek eingeführt . Das NET 5-Code-Analysator- / Generator-Paket wurde als Hilfsprogramm konzipiert, das einfachen Code zum Erstellen von Objekten im reinen DI- Stil unter Verwendung von Hinweisen zum Erstellen eines Abhängigkeitsdiagramms schreibt . Es überwacht Änderungen, analysiert Typen und Abhängigkeiten zwischen ihnen, hebt Probleme hervor und schlägt Lösungen vor. Es ist wichtig zu beachten, dass die Pure.DI- Bibliothek kein Abhängigkeitsinjektionscontainer ist. Zu ihren Aufgaben gehören:





  • Analyse des Abhängigkeitsgraphen





  • Definition von Problemen und Lösungsmöglichkeiten





  • Erstellen von effizientem Code für die Objektzusammensetzung





Aus den Diskussionen im vorherigen Beitrag habe ich den Eindruck gewonnen, dass die folgenden Probleme behoben werden müssen:





  • Fügen Sie die Möglichkeit hinzu, Pure.DI in ASP.NET Framework zu verwenden





  • Entfernen Sie die binäre Abhängigkeit von der API aus dem Pure.DI.Contracts- Paket





  • Erhöhen Sie die Leistung in Fällen, in denen die Operation Resolve()



    mehrmals ausgeführt wird





Nach geringfügigen Verbesserungen erkennt der Code-Analysator nun automatisch, ob es sich bei einem ASP.NET- Projekt um ein Projekt handelt, und generiert einen benutzerdefinierten Code für Erweiterungsmethoden, der die Integration in ASP.NET ermöglicht . Um diese Funktion zu demonstrieren, habe ich eine Blazor-Serveranwendung ausgewählt :





:





DI.Setup()
  .Bind<IDispatcher>().As(Singleton).To<Dispatcher>()
  .Bind<IClockViewModel>().To<ClockViewModel>()
  .Bind<ITimer>().As(Scoped).To(_ => new Timer(TimeSpan.FromSeconds(1)))
  .Bind<IClock>().As(ContainerSingleton).To<SystemClock>();
      
      



DI   ASP.NET :





services.AddClockDomain();
      
      



, -, . , :





  • ContainerSingleton - ASP.NET





  • Scoped - ASP.NET scope





ASP.NET, .





API “” Pure.DI.Contracts. API “ ” , API . , , analyzers Pure.DI . , , , “ - ”.





ASP.NET Framework ruft Resolve()



für jede Anforderung eine Methode auf. Um den Overhead dieses Aufrufs zu verringern, wurde der Code optimiert, der für die Zuordnung des Stammelementtyps einer Objektzusammensetzung zur Erstellungsmethode dieser Zusammensetzung verantwortlich ist. Die Ergebnisse der Vergleichstests finden Sie hier . Ich möchte betonen, dass dieser Vergleich eine kontroverse Methode zur Ermittlung von Leistungsmetriken verwendet. Daher geben diese Ergebnisse eine grobe Schätzung des Overheads mehrerer Methodenaufrufe Resolve()



.





Konstruktive Kommentare und Ideen werden wie immer sehr geschätzt.








All Articles