Dependency Injection Constructor Performance

Question

My team is considering switching to constructor dependency injection (ASP.NET Web API/Web Forms with Autofac and EF). One of the larger concerns is what kind of performance hit will be incurred by the ASP.NET/Autofac system constructing/destructing all the objects needed to compose the full dependency chain - at a minimum, each request would construct/dispose

• controller
• business logic (singleton candidate)
• data access (singleton candidate)
• EF model context

Architectural considerations aside, focusing mainly on runtime and memory usage, is there a noticeable performance hit incurred by constructing/destructing the entire stack each request , as compared to doing something like resolving the business logic/data access components to singleton instances? My thought would be that with all the weight of setting up the request pipeline, controller, and EF context, adding the business logic/data access construction would not contribute much additional overhead, but I would like to see if the community has had any experience with this comparison before we attempt it.

Answer 1

is there a noticeable performance hit incurred by constructing/destructing the entire stack each request

There should be no noticeable hit since the constructor should ideally be used to do just that, construct .

The framework was designed with DI built-in.

Reference Dependency Injection in ASP.NET Web API 2

Controllers and DbContext are constructed per HTTP request. Everything else injected into the controller would be dependent on the lifetime scope used to register it with the container. Transient , Singleton or Scoped .

There should be no heavy action done in the constructor.

It's important to understand that when using Constructor Injection the constructor should contain no additional logic.

An Injection Constructor should do no more than receiving the dependencies.

Reference Injection Constructors should be simple