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

【问题标题】：Does adding a lot of repositories to the Startup.cs cause any issues?向 Startup.cs 添加大量存储库会导致任何问题吗？
【发布时间】：2018-08-29 14:43:59
【问题描述】：

所以...在我的 .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。从技术上讲，这避免了这个问题，但我想避免这是一个麻烦。

【问题讨论】：

最好的回答方法是对此进行基准测试。
好吧，`服务器或内存的任何问题`->注册将使用内存。除非在链接回注册的范围内解决依赖项，否则不会创建实例。注册本身使用的 RAM 量相对可以忽略不计。也就是说，如果您在 Raspberry Pi 上运行，您可能需要重新考虑您的方法。 if there is a better way to scope a ton of repositories - 我会使用反射，这样您就不必手动列出它们
有一个更好的方法：忘记存储库模式并使用 Entity Framework Core，因为它应该被使用
我们正在部署到 Azure 服务器，因此内存不应该像 Rasberry Pi 那样非常昂贵 :) @CamiloTerevinto - 我愿意接受更改，但我需要比“你糟透了”更多的细节。
@zaitsman 你能指出我谈论以这种方式使用反射的地方吗？谢谢！

标签： c# asp.net-core

【解决方案1】：

无论是否将存储库模式与实体框架（核心）一起使用是否是一个好主意，通常注册服务很多都没有问题。

大型应用程序很容易最终拥有大量必须向依赖注入容器注册的服务。它的工作方式，每个注册实际上只是列表中的一个项目。所以有很多注册完全没有问题。 ASP.NET Core 在内部已经自行注册了很多服务。

对于注册来说，每个服务的生命周期是多少也无关紧要。那里的每个注册基本上都是相同的，生命周期只是与注册类型一起存储的配置。

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

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

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

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

【讨论】：