在項目中用到EntityFramework Core都是現學現用，及時發現問題及時測試，私下利用休閑時間也會去學習其他未曾遇到過或者用過的特性，本節我們來講講在EntityFramework Core 1.1中出現了哪些新特性供我們使用。
在EF 6.x中也有此方法的實作，在EF Core 1.1中也同樣對此方法進行了實作，為什麼要拿出來講呢，當然也有其道理，我們一起來看看。在倉儲中我們實作Find這個方法，如下：
此時我們來查詢Blog中主鍵等于1的資料。
此時我們通過SQL Server Profiler監控得到如下SQL。
我們看到通過Find方法來查詢主鍵等于1的資料時，聲明了一個變量然後再來進行設定變量值進行查詢，沒毛病，上述我們是直接通過Find方法來實作，下面我們通過其他幾種方法來實作。如下：
此時和上述Find方法執行的SQL無任何差別，我們先别着急下結論，我們再來通過lambda表達式來實作看看。
此時我們再來看看生成的SQL語句。
此時生成的SQL語句沒有聲明變量看起來非常清爽，同時看過dudu老大剛不久寫過在EF Core中我們聲明的的lambda表達式中的參數就是我們查詢表的别名，确實是如此，不知道你發現了沒有。既然以上有多種實作且利用lambda表達式實作更加清爽，那麼為何還要搞出一個Find方法呢，請繼續往下看。
當我們第一次查詢了主鍵等于1的資料時，我們第二次通過Find方法再來進行查詢時通過監控SQL Server Profiler，你會發現并未生成任何SQL語句，這說明什麼呢，說明EF Core團隊給出Find方法的目的在于：當實體已經被加載到上下文中時，我們通過Find方法再去查詢資料時此時不會再去資料庫中進行查詢。是以當我們利用主鍵查詢資料時利用Find方法會減少對資料庫的多次請求。
在之前EF版本中我們都是進行如下聲明字段
我們知道在EF Core中已經不存在延遲加載這一概念，是以請用了EF Core的童鞋将virtual關鍵字去掉。同時我們在映射集合時一直以來都統一用的ICollection<T>，但是在EF Core中不再有此局限性，我們進行如下定義：
通過如上我們知道現在支援了IEnumerable<T>集合的映射。當然這裡有個前提，其具體集合類必須實作ICollection接口，否則EntityFramework Core将無法進行填充。
這個特性應該是前所未有，隻有在EF Core 1.1中才出現，我們詳細講解下Backing Fileds（我們暫且将其翻譯為傳回字段）特性。自從有了如下自動屬性的出現，就友善了我們許多。
什麼是傳回字段（Backing Fileds）特性，我們先看下原始為字段配置屬性的情況如下：
Backing Fileds特性允許EF Core讀或者寫資料到字段中而不是屬性中。也就是說如上EF Core将資料讀寫到_url字段中而不是Url中。預設情況下滿足以下四種規則都會配置成Backing Fileds。
<code>_<camel-cased property name></code>
<code>_<property name></code>
<code>m_<camel-cased property name></code>
<code>m_<property name></code>
比如屬性為UserName，那麼對應的Backing Fileds則依次是：_userName，_UserName，m_userName，m_UserName。配置Backing Fileds後，當從資料庫查詢類執行個體後将直接将其對應資料寫到字段中，在其他時候當EF Core需要讀或者寫值時有可能使用屬性，例如EF需要更新一個屬性上的值時，此時将使用屬性的set通路器，如果屬性僅僅隻是隻讀，那麼将值寫到字段中。例如如下配置Backing Fileds即_validateUrl。
我們也可以在映射中配置使用屬性還是字段，如下：
若我們在實體中沒有屬性，此時我們可以通過字段來存儲資料。我們通過映射中的Porperty(...)來指定字段名稱，若沒有屬性，此時EF Core将會查找字段，如下：
講了這麼多Backing Fileds特性，不知道看到本篇文章的你清楚了它的作用是什麼，為什麼要提出Backing Fileds特性，它存在的價值或者說用途是做什麼呢，就我個人的了解的話，提出Backing Fileds的多數場景在：如果屬性隻讀，我們需要通過其他邏輯操作來擷取其值，但是我們沒有一個橋梁來賦予其值，此時我們就需要Backing Fileds來完成。希望看到此文的你有更多見解的話，請留下評論，一起探讨。這裡我們結合上述IEnumerable<T>來進一步講解Backing Fileds。我們在Blog類中是如下定義。
我們知道對于導航屬性Posts更多的是通過Inlcude來查詢出Posts，是以在這裡我們完全不需要set通路器以便減少對Posts反編譯為Set方法，我們完全可以改造如下：
話又說回來了，如果我們萬一需要對Post進行一些操作，那麼在這種情況下該如何是好呢，此時我們通過暴露IEnumerable<Blog>導航屬性，然後借助該導航屬性的Backing Fileds來對Post進行操作，改造如下：
我們實際來操作一下，查詢Blog資料以及導航屬性Post資料。
我們進行如下查詢：
我們上述稍微改造了一下，為了以免查詢出現錯誤，測試查詢一下，如下，沒毛病。
貌似顯式加載沒有什麼應用的場景，不知道是否是應對某些特定的場景而給，它隻是加載被上下文跟蹤實體的導航屬性，通過Include我們也可以實作，如下：
所謂的連接配接彈性則是執行資料庫指令失敗時我們可以重試，我們可以在OnConfiguring或者Startup.cs中設定，如下：
記憶體優化表是SQL Server的一個特性，它将整個表駐留在記憶體中，在磁盤上保留着對表的副本，主要是用于持久化，在資料庫恢複時（比如重新開機）在記憶體優化表中的資料從磁盤上僅僅隻是進行讀取。比如對Blog表進行記憶體優化設定，如下：
将實體映射到記憶體優化中的表，當使用EF Core基于我們的模型建立資料庫時，此時這些實體也将在記憶體優化表中建立一份。
在EF Core 1.0中就可以實作服務更換，但是略顯複雜，在EF Core 1.1中替換服務類似于依賴注入一樣，如下：
在EF 6.x之前版本中因為導航屬性的存在很容易導緻循環引用，是以對于EF Core同樣是如此我們需要在Startup.cs中忽略循環引用，如下：
本節我們比較詳細的講解了EF Core 1.1中新添加或改善的特性，我們重點講述了Backing Fileds特性。