故事背景

最近在把自己的一個老項目從Framework遷移到.Net Core 3.0，數據訪問這塊選擇的是EFCore+Mysql。使用EF的話不可避免要和DbContext打交道，在Core中的常規用法一般是：創建一個XXXContext類繼承自DbContext，實現一個擁有DbContextOptions參數的構造器，在啟動類StartUp中的ConfigureServices方法里調用IServiceCollection的擴展方法AddDbContext，把上下文注入到DI容器中，然后在使用的地方通過構造函數的參數獲取實例。OK，沒任何毛病，官方示例也都是這么來用的。但是，通過構造函數這種方式來獲取上下文實例其實很不方便，比如在Attribute或者靜態類中，又或者是系統啟動時初始化一些數據，更多的是如下一種場景：

public class BaseController : Controller  {    public BloggingContext _dbContext;    public BaseController(BloggingContext dbContext)    {      _dbContext = dbContext;    }    public bool BlogExist(int id)    {      return _dbContext.Blogs.Any(x => x.BlogId == id);    }  }  public class BlogsController : BaseController  {    public BlogsController(BloggingContext dbContext) : base(dbContext) { }  }

從上面的代碼可以看到，任何要繼承BaseController的類都要寫一個“多余”的構造函數，如果參數再多幾個，這將是無法忍受的（就算只有一個參數我也忍受不了）。那么怎樣才能更優雅的獲取數據庫上下文實例呢，我想到以下幾種辦法。

DbContext從哪來

1、 直接開溜new

回歸原始，既然要創建實例，沒有比直接new一個更好的辦法了，在Framework中沒有DI的時候也差不多都這么干。但在EFCore中不同的是，DbContext不再提供無參構造函數，取而代之的是必須傳入一個DbContextOptions類型的參數，這個參數通常是做一些上下文選項配置例如使用什么類型數據庫連接字符串是多少。

 public BloggingContext(DbContextOptions<BloggingContext> options) : base(options)    {    }

默認情況下，我們已經在StartUp中注冊上下文的時候做了配置，DI容器會自動幫我們把options傳進來。如果要手動new一個上下文，那豈不是每次都要自己傳？不行，這太痛苦了。那有沒有辦法不傳這個參數？肯定也是有的。我們可以去掉有參構造函數，然后重寫DbContext中的OnConfiguring方法，在這個方法中做數據庫配置：

  protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)    {      optionsBuilder.UseSqlite("Filename=./efcoredemo.db");    }

即使是這樣，依然有不夠優雅的地方，那就是連接字符串被硬編碼在代碼中，不能做到從配置文件讀取。反正我忍受不了，只能再尋找其他方案。

2、 從DI容器手動獲取

既然前面已經在啟動類中注冊了上下文，那么從DI容器中獲取實例肯定是沒問題的。于是我寫了這樣一句測試代碼用來驗證猜想：