WPF应用中直接实例化DbContext与构造函数注入的对比分析

在WPF应用中，相较于在using块中直接实例化数据库上下文（DbContext），采用构造函数注入数据库上下文究竟有哪些优势？以下两个示例均可正常运行，哪种方案更优？原因是什么？

示例1：直接实例化AppDbContext #

MainWindow #

public partial class MainWindow : Window
{
    public MainWindow()
    {
        InitializeComponent();

        using (AppDbContext context = new AppDbContext())
        {
            var people = context.People.ToList();
            // 处理people数据
        }
    }
}

AppDbContext #

public class AppDbContext : DbContext
{
    public DbSet<Person> People { get; set; }

    public AppDbContext()
    {

    }

    public AppDbContext(DbContextOptions options) : base(options)
    {

    }

    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        optionsBuilder.UseSqlServer({DB_CONNECTION_STRING});

        base.OnConfiguring(optionsBuilder);
    }
}

示例2：构造函数注入AppDbContext #

MainWindow #

public partial class MainWindow : Window
{
    private readonly AppDbContext context;

    public MainWindow(AppDbContext context)
    {
        InitializeComponent();
        this.context = context;

        var people = context.People.ToList();
        // 处理people数据
   }
}

App.xaml.cs #

public partial class App : Application
{
    public static IHost? AppHost { get; private set; }

    public App()
    {
        var builder = Host.CreateDefaultBuilder();

        AppHost = builder.ConfigureServices((hostContext, services) =>
        {
            services.AddSingleton<MainWindow>();
            services.AddDbContext<AppDbContext>(options => 
                options.UseSqlServer({DB_CONNECTION_STRING}));
        }).Build();
    }

    protected override async void OnStartup(StartupEventArgs e)
    {
        await AppHost!.StartAsync();

        AppHost.Services.GetRequiredService<MainWindow>().Show();

        base.OnStartup(e);
    }

    protected override async void OnExit(ExitEventArgs e)
    {
        await AppHost!.StopAsync();

        base.OnExit(e);
    }
}

结论：示例2（构造函数注入）更优，核心优势如下 #

• 解耦与可维护性：直接实例化时，MainWindow硬绑定了AppDbContext的创建逻辑，后续更换数据库类型、调整上下文配置都得修改MainWindow的代码；注入方式下，上下文的配置集中在服务注册环节，MainWindow只依赖DbContext抽象，业务代码和基础设施代码彻底分离，维护成本更低。
• 灵活的生命周期管理：EF Core的AddDbContext默认注册为Scoped生命周期（WPF中可对应作用域实例），容器会自动处理上下文的创建与释放，无需手动编写using。如果需要在多个组件间共享上下文（比如跨窗口执行事务），只需修改服务注册的生命周期配置，不用改动业务代码。
• 单元测试更便捷：注入方式下，写单元测试时可以轻松用Mock框架（如Moq）创建假的DbContext，脱离真实数据库验证业务逻辑；直接实例化的话，要么依赖真实数据库，要么得修改原有代码添加测试分支，效率极低。
• 配置集中管控：连接字符串等配置集中在服务注册处，不会分散在各个new AppDbContext的地方，后续修改配置只需调整一处，避免遗漏。
• 符合依赖倒置原则：高层模块（MainWindow）不依赖低层模块（AppDbContext的具体实现），而是依赖抽象（DbContext），代码结构更健壮，后续扩展新功能时更不容易出问题。

另外补充一点：示例1中每个using都会创建新的上下文实例，若多个操作需要共享上下文（比如跨方法的事务），实现起来会非常繁琐；而注入方式可以通过生命周期控制轻松实现上下文共享，简化复杂业务场景的开发。

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