Entity Framework：DbContext为何是具体类而非抽象类？

这个问题问得特别好——我刚接触EF的时候也琢磨过：明明我们几乎都是通过继承DbContext来开发自己的数据上下文，为啥它不做成抽象类呢？其实背后有几个非常实际的设计考量：

• 支持快速验证的轻量场景
  有时候你只是想快速验证一个数据库操作的想法，或者写个小脚本/工具，完全没必要自定义一个继承类。比如你可以直接实例化DbContext来完成简单任务：

  var options = new DbContextOptionsBuilder()
      .UseSqlServer("YourConnectionString")
      .Options;
  
  using (var context = new DbContext(options))
  {
      // 直接查询、插入临时数据等操作
  }
  

  这种设计降低了EF的入门门槛，让新手不用先写一堆模板代码就能上手。

• 向后兼容性的硬性要求
  EF从早期版本（比如EF 4.1引入DbContext）开始就把它设计成了具体类。如果后续版本改成抽象类，所有现有项目中继承DbContext的代码都会直接编译失败——这对微软来说是绝对不能接受的，毕竟要保证数百万现有用户的代码平稳迁移。

• 开箱即用的核心默认实现
  DbContext内部封装了大量EF的核心逻辑：变更追踪、事务管理、SaveChanges的默认提交逻辑、模型构建的默认规则等等。如果把它做成抽象类，这些核心功能要么得变成抽象方法强制子类实现（这显然违背了“不要重复造轮子”的原则），要么得用复杂的方式提供默认实现。而具体类可以直接把这些功能打包好，用户继承后只需要关注自己的实体定义和业务逻辑，不用操心底层运作。

• 灵活的扩展与定制方式
  虽然继承是最常用的方式，但具体类允许你有更多扩展选择：比如用部分类补充上下文逻辑，或者通过依赖注入包装它；而且继承具体类时，你只需要重写你需要自定义的方法（比如OnModelCreating来配置模型），其他所有核心功能都可以直接用默认实现——这比抽象类要求你必须实现所有抽象方法要友好得多，降低了用户的开发负担。

本质上来说，EF的设计团队是把实用性和用户体验放在了设计原则的前面。严格来说，“被继承的类应该是抽象类”是一个通用的设计指导，但并不是铁律——当这个原则会影响用户上手、兼容性或功能便利性时，优先满足实际需求才是更合理的选择。

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