Blazor DI与EF/DbContext结合私有NuGet包的复用配置问题

Blazor 采用全局单根DI容器设计，NuGet包本身不存在独立的DI隔离容器，所有服务注册逻辑最终都会合并到宿主应用的IServiceCollection中生效。你在工单系统原始项目中编写的DI配置、EF上下文注册代码属于项目启动逻辑，不会被自动打包进NuGet包的执行逻辑中，这就是你需要在宿主项目重复配置的核心原因。

你只需要把内部需要的所有DI配置封装成公开的服务注册扩展方法，即可把宿主配置步骤压缩到最低：

1. 在你的NuGet包项目中新增服务扩展静态类

using Microsoft.EntityFrameworkCore;
using Microsoft.Extensions.DependencyInjection;

namespace YourTicketPackageNamespace
{
    public static class TicketSystemServiceExtensions
    {
        // 仅暴露连接字符串作为唯一必填参数
        public static IServiceCollection AddTicketSubmitComponent(this IServiceCollection services, string dbConnectionString)
        {
            // 所有内部依赖全部在此处注册，完全对宿主屏蔽实现细节
            services.AddDbContextFactory<TicketDbContext>(opt => 
                opt.UseSqlServer(dbConnectionString));
            // 注册你内部用到的仓储、业务服务等
            services.AddScoped<ITicketSubmitService, TicketSubmitService>();
            
            return services;
        }
    }
}

2. 宿主项目仅需做两步配置：
   • 在appsettings.json中添加工单系统连接字符串

   {
     "ConnectionStrings": {
       "TicketSystem": "你的SQL Server连接字符串"
     }
   }
   

   • 在Program.cs中调用扩展方法完成注册

   builder.Services.AddTicketSubmitComponent(builder.Configuration.GetConnectionString("TicketSystem"));
   

不需要宿主手动配置EF、DbContextFactory等任何内部依赖，所有实现细节完全封装在NuGet包内。

• 是否可以完全免DI配置？
  不可能，连接字符串是每个宿主项目的专属配置，不可能硬编码在NuGet包中，上述方案已经是最低配置的实现方式。
• 如何避免和宿主的EF配置冲突？
  给你的TicketDbContext加上唯一命名空间，不要和宿主项目的上下文类重名即可，EF Core支持同一项目注册多个不同的DbContextFactory，不会互相干扰。
• 依赖包处理：打包时要把你用到的Microsoft.EntityFrameworkCore.SqlServer等依赖设置为随NuGet包自动安装，宿主不需要手动安装这些依赖。

内容的提问来源于stack exchange，提问作者aterbo