上一節我們針對最開始拋出的異常只是進行了淺嘗輒止的解析，是不是有點意猶未盡的感覺，是的，我也有這種感覺，看到這里相信您和我會有一些疑惑，要是我們接下來通過注解、Fluent APi、DbSet分別對表名進行如下設置，那么其優先級到底是怎樣的呢？內置具體是如何實現的呢？讓我們從頭開始揭開其神秘的面紗。

既然涉及到表名解析優先級，那么接下來我們進行如下配置，模型請參考上一節內容

在還未進入原理解析之前，讓我們大膽猜測通過如上配置后優先級將是怎樣的呢？是Fluent Api > 注解 > DbSet > 約定嗎？假設是這樣的話，EntityFramework Core內置是怎樣實現的呢？是采用覆蓋的機制嗎？

一堆疑問浮現在我們眼前，來，讓我們進入探究枯燥源碼的世界，為您一一解惑。首先我們需要明確的是，在我們實例化上下文進行操作之前，EntityFramework Core具體做了些什么？故事就要從我們派生自DbContext上下文說起，如下：

在EntityFramework Core中我們利用上下文進行操作之前就是按照上述代碼由上至下整體上做了如下三步準備工作：

【1】實例化上下文時，查找DbSet屬性并緩存到內存中。

【2】以上下文作為緩存的鍵，獲取緩存在內存中的模型數據。

【3】若未緩存，則創建上下文中所有模型有關數據。

查找DbSet屬性并緩存

接下來我們步步分析，步步逼近以上三步操作實現，無論是主動實例化還是在Web中添加上下文中間件時，都必須經過將我們需要用到所有接口進行依賴注入

當然EntityFramework Core引用的是.NET Core中依賴注入庫，至于注冊了哪些，這些細節我們并不關心，我們只關注所需要用到的且會一一說明，獲取接口IDbSetInitializer的具體實現DbSetInitializer，調用該類中的如下方法：

接下來獲取接口IDbSetFinder的具體實現DbSetFinder去過濾查找存在Setter屬性的DbSet（這點就不用我解釋），查找細節我們不關心，每個DbSet都有其DbSetProperty屬性，所以查找到后添加到該屬性并緩存到IDbSetCache中，到此對于DbSet的查找和緩存就已完事，接下來去創建上下文中的所有模型數據。

創建上下文模型

首先是去獲取上下文中所有模型數據，以上下文為鍵去查找緩存的模型數據，若沒有則創建，否則創建緩存，如下：

接下來到了緩存不存在創建模型的環節，創建模型主要做了以下三件事。

當實例化ModelBuilder通過約定分發機制處理各個約定，具體做了哪些操作呢？主要做了以下三件事

【1】各個約定進行初始化做一些準備工作，并將其添加到對應約定集合中去。

【2】遍歷自定義約定插件集合，修改對應默認約定并返回最新約定集合。

【3】通過約定分發機制，處理獲取得到的最新約定集合。?

上述第【1】和【2】步通過如下代碼實現：

EntityFramework Core內置提供了三個創建默認約定集合提供者接口IProviderConventionSetBuilder的具體實現，三者屬于繼承關系。

【1】ProviderConventionSetBuilder:構建針對數據庫使用的默認約定集合的提供者

【2】RelationalConventionSetBuilder:構建模型與數據庫映射的默認約定集合的提供者

【3】SqlServerConventionSetBuilder:針對SQL Server數據庫構建默認約定集合的提供者

我們用不到的約定已經剔除，上述向實體類型添加約定集合中先后添加了RelationalTableAttributeConvention和TableNameFromDbSetConvention對于表名的約定，對于TableNameFromDbSetConvention約定在構造實例化時做了如下操作：

我們繼續看上述通過上下文是如何獲取對應模型的DbSet屬性的呢？

因為在初始化上下文時我們就已經對上下文中的所有DbSet屬性進行了緩存，所以通過如上方法就是獲取模型與對應上下文緩存的DbSet屬性的映射，還是很好理解，如下也給出調試源碼時所顯示Blog對應的DbSet屬性信息。

現在我們已經獲取到了所有默認約定集合，接下來實例化ModelBuilder，將默認約定集合作為參數傳進去，如下：

接下來繼續實例化Model，傳入默認約定集合，開始實例化約定分配類并通過約定分發機制對模型進行處理，如下：

上述ConventionDispatcher類就是對模型的各個階段進行分發處理，關于分發處理機制后續再單獨通過一篇文章來詳細分析，因為上述我們將表名的兩個約定放在EntityTypeAddedConventions集合中，接下來我們來到約定分發機制對該約定集合中12個默認約定遍歷處理，如下：

因為首先添加的RelationalTableAttributeConvention約定，所以當遍歷到RelationalTableAttributeConvention約定時，就去到處理該約定的具體實現，說白了該約定就是獲取表名的注解即遍歷特性，如下：

方法ProcessEntityTypeAdded的最終具體實現就是設置對應具體模型的表名，如下：

有童鞋就問了，我們在表特性上只定義架構名稱，那么上述不就產生bug了嗎，用過注解的都知道既然在表特性上提供了架構名稱，那么表名必須提供，但是表名提供，架構名稱可不提供，所以上述處理邏輯并沒任何毛病。? ??

我們繼續看上述在RelationalEntityTypeBuilderExtensions類中對于ToTable方法的實現，如下：

我們看到該方法主要目的是判斷該表名是否可設置，若不可設置則返回空，否則將設置該注解的名稱作為模型的表名，我們看看上述CanSetTable又是如何判斷是否可設置呢？

注：RelationalAnnotationNames.TableName是專為通過注解獲取表名而定義的常量其值為Relational:TableName

真是一層套一層，此時在注解字典中不存在該鍵，最終當然也就將模型的表特性名稱作為模型的表名，如下：

上述就是ToTable方法中調用第一個方法CanSetTable是否可設置表名的過程，主要就是在注解字典中查找注解名稱為Relational:TableName是否已存在的過程，我們可以看到注解字典中不存在表名的注解名稱，接下來調用第二個方法SetTableName方法去設置表名

接下來將是向注解字典中添加名為Relational:TableName，值為Blog2的注解，通過如下圖監視可以清楚看到：

到目前為止，對于模型Blog已經通過注解即表特性設置了表名，接下來處理約定TableNameFromDbSetConvention，到底是覆蓋還是跳過呢？我們還是一探其實現，如下：

首先獲取模型Blog的元數據，接下來判斷其基類是否為空，該類型的原始類型不能為空，同時在其暴露的DbSet屬性中包含該類型，很顯然都滿足條件，最后將我們上述對模型和DbSet屬性進行了映射，所以設置其表名為Blog1，如下：

如上只是滿足了條件進行設置，我們還要看看方法ToTable的具體實現才能最終下結論，此時依然會和注解判斷邏輯一樣，但是此時在注解字典中已存在鍵Relational:TableName，所以將跳過，如下：

好了，到此為止針對注解和DbSet對表名的設置已經討論完畢，接下來我們進行到執行OnModelCreating方法即我們自定義的設置即如下代碼：

此時將執行到我們對Blog自定義設置的表名Blog3，我們看看最終其ToTable方法直接跳過了CanSetTable方法，直接將參數名稱賦值作為模型表名。

到此為止對模型的初始化準備工作已經完成，接下來開始利用上下文進行操作，此時我們回到上一節利用上下文獲取表名的方法，如下：

通過分析可知，無論是根據DbSet配置表名還是通過注解配置表名又或者是通過在OnModelCreating方法中自定義配置表名，最終在落地設置時，都統一以Relational:TableName為鍵設置表名值，所以上述若基類不存在就獲取該表名常量的值，否則都未配置表名的話，才去以模型名稱作為表名。

通過此篇和上一篇我們才算對EntityFramework Core中表名的詳細解析才算明朗，我們下一個結論：EntityFramework Core對于表名的配置優先級是自定義（OnModelCreating方法）> 注解（表特性）> DbSet屬性名稱 > 模型名稱，可能我們會想何不先注冊DbSet約定，然后再注冊表特性約定，采取覆蓋的機制呢？但是事實并非如此，這里我們僅僅只是研究源碼的冰山一角或許是為了考慮其他吧。若暴露DbSet屬性，根據注冊的默認約定表名為DbSet屬性名稱，否則表名為模型名稱，若通過注解設置表名，此時上下文中暴露的DbSet屬性將會被忽略，若通過OnModelCreating方法自定義配置表名，則最終以其自定義表名為準。那么問題隨之又來了，對于屬性是否可依此而類推呢？這個問題，只能您親自去看源碼一探究竟了。

總結

以上是生活随笔為你收集整理的EntityFramework Core表名原理解析，让我来，揭开你神秘的面纱的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。