Question

所以...在我的.Net Core 2启动文件中，我将存储库添加到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等），这才变得相对昂贵，因为这里只有很多依赖关系得到解决。

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

在Startup.cs中添加大量存储库是否会引起任何问题？

1 个答案: