Pure.DI next step

Recently in this post you were introduced to the Pure.DI library . NET 5 code analyzer / generator package was conceived as a helper that writes simple code to compose objects in pure DI style using hints to build a dependency graph. It monitors changes, analyzes types and dependencies between them, highlights problems and suggests solutions. It is important to note that the Pure.DI library is not a dependency injection container, its tasks include:





  • dependency graph analysis





  • definition of problems and ways to solve them





  • creating efficient code for object composition





From the discussions in the previous post, I got the impression that the following issues need to be addressed:





  • add the ability to use Pure.DI in ASP.NET framework





  • remove the binary dependency on the API from the Pure.DI.Contracts package





  • increase performance for cases where the operation Resolve()



    is performed multiple times





Now, after minor improvements, the code analyzer automatically detects whether an ASP.NET project is a project and generates a custom extension method code that provides integration with ASP.NET . To demonstrate this feature, I chose a Blazor server application :





:





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 calls a method Resolve()



for every request. To reduce the overhead of this call, the code responsible for mapping the root element type of an object composition to the creation method of that composition has been optimized. The results of the comparative tests can be found here . I would like to emphasize that this comparison uses a controversial way of obtaining performance metrics. Therefore, these results give a rough estimate of the overhead of multiple method calls Resolve()



.





As usual, any constructive comments and ideas are greatly appreciated.








All Articles