Does adding a lot of repositories to the Startup.cs cause any issues?

Question

So... in my .Net Core 2 Startup file I am adding my repositories to the scope in the ConfigureServices method like so...

public void ConfigureServices(IServiceCollection services)
{
    var config = LoadConfiguration();
    services.AddDbContext<DatabaseContext>(options => options.UseSqlServer(config.Connection, x => x.MigrationsAssembly("XXX")));

    // Repositories
    services.AddScoped<IUserRepository, UserRepository>();
    services.AddScoped<ISecurityFunctionRepository, SecurityFunctionRepository>();
    services.AddScoped<IUserSecurityFunctionRepository, UserSecurityFunctionRepository>();
    services.AddScoped<ICustomerRepository, CustomerRepository>();
    // ... lots more...

    // other goodies
}

I know there are a million ways to setup a .Net Core 2 API, but my specific question is whether or not having 30+ repositories added to scope will cause any issues with the server or memory, OR if there is a better way to scope a ton of repositories.

In other projects I have created several APIs with their own repositories. That technically avoids this issue, but it is a hassle I would like to avoid.

Well, ` any issues with the server or memory` -> the registrations will use memory. The instances will not be created unless a dependency is being resolved in-scope that chains back to the registrations.The amount of RAM used by registrations themselves is relatively negligible. That said, if you are running on Raspberry Pi, you may want to rethink your approach. `if there is a better way to scope a ton of repositories` - i'd use reflection just so you don't have to list em out manually — zaitsman, Aug 29 '18 at 14:47
There is a better way: forget about the repository pattern and use Entity Framework Core as it is supposed to be used — Camilo Terevinto, Aug 29 '18 at 14:49
We are deploying to Azure servers, so memory shouldn't be at quite the premium as a Rasberry Pi :) @CamiloTerevinto - I am open to changes but I need more specifics than "you suck". — David, Aug 29 '18 at 14:55
@zaitsman can you point me somewhere that talks about using reflection in this way? Thanks! — David, Aug 29 '18 at 14:56
I didn't say that, but people think they need the repository pattern. The reality is that EFCore implements it on the DbContext so you are adding an abstraction over an abstraction which makes no sense (in 99% of projects where actually removing EFCore isn't a possibility/something that will be done). I've answered [here](https://stackoverflow.com/a/50457230/2141621) about this — Camilo Terevinto, Aug 29 '18 at 15:07

score 4 · Accepted Answer · answered Aug 29 '18 at 16:31

Regardless of whether it’s a good idea to use the repository pattern with Entity Framework (Core) or not, generally there is no problem with having many registered services.

Large applications will easily end up having a very high number of services that have to be registered with the dependency injection container. The way it works, every registration is not really more than an item in a list. So there’s no problem with having many registrations at all. ASP.NET Core internally will already register a lot of services on its own.

It also does not matter for the registration what the lifetime of each service is. Every registration will basically be identical there, and the lifetime is just a configuration that is stored with the registered types.

You will also have to remember that the registration will only happen once when your application starts, so even if there was a performance issue, it likely wouldn’t affect the application run-time.

What does matter however is what happens when a service gets resolved: Here, the lifetimes also make a difference. A singleton service will only ever have a single instance, so its construction will only run once. A transient service will result in a new instance on every resolve. And a scoped service will have at most one instantiation per request.

But if you do not depend on a service, then that service will also not be constructed. So if you have 30 scoped services, but there is only one that will be resolved on each request, then there is no issue with having those other ones. This would only get relatively expensive when you have a long dependency graph (e.g. service A depends on B and C, and those depend on D, E, F, G, … and so on) where it’s just a lot of dependencies that need to be resolved.

However, in general, there isn’t a problem with having many (smaller) services that have specific purposes and as such will only be used in certain parts of your application. That is actually probably a good idea to design your application.

Does adding a lot of repositories to the Startup.cs cause any issues?

1 Answers1