向Startup.cs添加大量存储库会导致任何问题吗？

Question

所以...在我的.Net Core 2 Startup文件中，我将我的存储库添加到ConfigureServices方法中的范围，就像这样......

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
}

我知道有一百万种方法可以设置.Net Core 2 API，但我的具体问题是，是否在服务器或内存中添加了30多个存储库会导致服务器或内存出现任何问题，或者是否有更好的方法来确定范围大量的存储库。

在其他项目中，我使用自己的存储库创建了几个API。这在技术上避免了这个问题，但这是一个我想避免的麻烦。

Answer 1

无论将存储库模式与Entity Framework（Core）一起使用是否是一个好主意，通常使用许多注册服务都没有问题。

大型应用程序很容易最终拥有必须在依赖注入容器中注册的大量服务。它的工作方式，每次注册都不会超过列表中的项目。所以注册很多都没有问题。 ASP.NET Core内部已经自己注册了很多服务。

注册与每项服务的生命周期无关。每个注册在那里基本相同，并且生命周期只是与注册类型一起存储的配置。

您还必须记住，注册只会在您的应用程序启动时发生一次，因此即使存在性能问题，也可能不会影响应用程序运行时。

然而，重要的是当服务得到解决时会发生什么：在这里，生命周期也会产生影响。单例服务只有一个实例，因此它的构造只运行一次。瞬态服务将导致每个解析的新实例。并且作用域服务每个请求最多只有一个实例化。

但是，如果您不依赖服务，那么也不会构建该服务。因此，如果您有30个范围的服务，但每个请求只有一个将被解析，那么拥有其他请求就没有问题。当你有一个很长的依赖图时（例如服务A依赖于B和C，那些依赖于D，E，F，G ......等等），这只会相对昂贵，因为它只需要很多依赖关系得到解决。

但是，一般来说，拥有许多（较小）服务具有特定目的并没有问题，因此只会在应用程序的某些部分使用。实际上，设计应用程序可能是个好主意。