迁移至.NET 8：如何在CoreWCF中为DbContext设置按调用作用域？

迁移背景 #

正在将WPF应用服务从.NET 4.7.2迁移至.NET 8，需通过.NET DI和CoreWCF管理DbContext生命周期。已为所有服务添加以下特性：

[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall, 
                 ConcurrencyMode = ConcurrencyMode.Single)]

当前依赖注入层级（含基类和分部类，所有服务、管理器、仓储均有对应实现）：

public partial class MyService
{
    public Manager MyManager { get; set;}

    public MyService(IMyManager myManager)
    {
        MyManager = myManager;
    }
}

public partial class MyManager
{
    public Repository MyRepository { get; set; }

    public MyManager(IMyRepository myRepository)
    {
        MyRepository = myRepository;
    }
}

public partial class MyRepository
{
    public DbContext MyDbContext { get; set; }

    public MyRepository(IMyDbContext dbContext)
    {
        MyDbContext = dbContext;
    }
}

所有服务、管理器、仓储及DbContext均通过.AddScoped()注册到DI容器中。

疑问与解答 #

1. [Injected]特性的使用范围 #

• 不需要为DI层级中的每个依赖（MyManager、MyRepository、DbContext）添加[Injected]特性。CoreWCF的DI容器会自动递归解析构造函数声明的依赖链，只要所有依赖已通过.AddScoped()注册，容器会自动创建并注入整个层级的实例。
• 连根依赖（如IMyManager）也不需要添加[Injected]特性。[Injected]主要用于属性注入场景，而你采用的是构造函数注入的最佳实践，CoreWCF会自动识别服务类构造函数中的参数并完成注入，无需额外标记。

2. 分部类对CoreWCF代码生成的影响 #

分部类不会影响CoreWCF的代码生成。CoreWCF在处理服务类时会自动合并同一类的所有分部定义，只要你的分部类符合C#语法规范（同一命名空间、相同类名），就不会出现问题。

针对你300+服务的规模，额外建议：

• 坚持使用构造函数注入，避免属性注入，保持依赖关系的清晰可维护；
• 采用程序集扫描的方式批量注册服务、管理器和仓储，减少重复注册代码；
• 当前InstanceContextMode.PerCall结合.AddScoped()的DbContext配置是合理的：每个服务调用会获得独立的DbContext实例，既符合PerCall的生命周期，又能避免DbContext的并发问题。

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