程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> .NET網頁編程 >> 關於.NET >> Entity Framework 6:專家版本

Entity Framework 6:專家版本

編輯:關於.NET

隨著 Entity Framework 最新主版本 EF6 的推出,Microsoft 對象關系映射 (ORM) 工具達到了新的專業高度,與久負盛名的 .NET ORM 工具相比已不再是門 外漢。 EF 已經完全成熟,正在超越以前廣泛使用的工具。

Entity Framework 已經度過了青澀期,它最初只是供數據庫開發者使用的工 具,後來在 .NET 社區的敏捷開發者中間引起轟動。 它學會了如何擺脫應用程序 開發模式,轉向了普通舊 CLR 對象 (POCO) 模型,支持以測試和域為中心的軟件 開發,同時沒有剝奪以數據為中心的開發者的使用權利。 一路走來,它解決了生 成代碼的性能問題和無數與質量有關的問題,並贏得了眾多數據庫管理員 (DBA) 的青睐。

從 EF 4.1 開始,Microsoft 認識到了 EF 所需的復雜性,通過推出 DbContext API 簡化了對其功能的訪問。 同時,由於不是所有人都想使用設計器 或生成代碼,它可以讓您利用自己的代碼生成模型。 在此期間,發生了另一項重 大變化,但不是功能、語法、代碼或性能的變化。 EF 團隊變得更加透明,與用 戶社區的互動更加頻繁,它開始更加流暢地提供功能發布,而不是將它們與 Microsoft .NET Framework 捆綁在一起。 自 2012 年 EF5 發布後,這種做法帶 來了兩個方面的進步。 首先,從 .NET Framework 中提取所有的 Entity Framework API,並與團隊同時正在開發的非常規功能 API 組合在一起。 其次, 整個開發工作改用了開源模型。 EF6 在以下網站中公開開發: entityframework.codeplex.com。 您不僅能通過會議記錄、簽入和可下載夜間生 成了解團隊所做的工作,還可以向 EF6 提供源代碼(但是要在 EF 團隊的完全監 督之下)。

請記住 EF6 是演變而不是革命。 幾乎您原先掌握的所有 EF 技能都沒有變化 ,例如如何生成 Entity Framework 模型以及如何在您的應用程序中使用 EF。 盡管 EF6 是在 ORM 基礎上發展而來的,但是並沒有改變它根本的工作方式。 如 果您已經投入時間學習 EF,那麼這種投入將不會白費。 EF6 在某些方面變化還 是比較大的,但是這些變化僅限於部分命名空間的變化,如果您有准備的話會很 容易處理。 我會在本文最後告訴您一些有幫助的資源。

我認為 EF6 的功能分為以下幾類:

免費提供的功能:這些功能屬於核心功能的一部分。 您甚至無需知道它們有 什麼作用,更不必說需要知道有什麼新的代碼了。 該組包括的功能有通過重寫視 圖生成引擎和查詢編譯修改來提高性能,由於 DbContext 能使用打開的連接而獲 得的穩定性,以及 Entity Framework 創建的 SQL Server 數據庫的更改設置。

級別設置功能:改進較大之處是 Code First 現在支持映射存儲過程,而在設 計器中創建的模型已支持此功能。 第 9 頻道視頻對此功能已進行了頗多介紹( 例如位於以下網址的視頻:bit.ly/16wL8fz),而且 CodePlex 網站提供了詳細 的規范介紹,所以我在本文中不再重復介紹這方面的信息。

另外一處更改更為 有趣。 正如我剛才提到的,EF6 的 EF API 是從 .NET Framework 中提取的;它 們現已完全封裝在 NuGet 程序包中。 這意味著 EF5 采用的部分功能(例如枚舉 、空間數據支持和性能改進)不再依賴於 .NET 4.5。 所以,如果您的 EF6 使用 的是 .NET 4,那麼這些功能最終會給您帶來幫助。

我也將 EF 設計器歸入了 這一類。 從 2013 版開始,Visual Studio 已取消此功能,但是作為 Visual Studio 的擴展功能提供。 對於 EF6 而言,將設計器作為擴展功能具有相當大的 好處。 以後團隊將能夠直接向設計器添加功能,包括 Entity Framework Power Tools 中當前提供的功能。 通過使設計器與 Visual Studio 分離,可以使 Microsoft 為 Visual Studio 2012 和 Visual Studio 2013 提供 EF6 工具。

專家功能:這些功能是基本 EF 應用程序示例所不具有的、您渴望擁有的功能 。 EF6 中有許多這樣的功能:支持異步查詢和保存、返回自定義 Code First 約 定、利用新的 DbConfiguration 類型提高可擴展性(依賴於較低級別的 EF6 IDbDependency 解析程序)、支持單元測試模擬、可配置不穩定連接的重試次數 等。 您無需成為認證專家就能使用這些功能,但您在使用時肯定會感覺像專家。

我還想重點介紹一個特殊類別:由社區成員貢獻的 EF6 代碼。 Unai Zorrilla 添加了 DbSet.Add­Range 和 RemoveRange,利用它們可以自定義 復數化和方便的 DbChangeTracker.HasChanges 方法。 他還在開發供 EF 將來迭 代使用的其他很酷的功能。 Erik Jensen 是一位 SQL Server Compact (SQLCE) MVP,他貢獻的 SQLCeFunctions 與 LINQ to Entities 查詢使用的 SQL Server 函數 SqlFunctions 非常相似。 EF 視圖生成速度的大幅提高(對於大型復雜模 型最為顯著)要歸功於 Alireza Haghshenas 和一位名為 VSavenkov 的 CodePlex 成員。 在 Iaki Elcoro(即 CodePlex 上的 iceclow)的幫助下,現 在還可以定義自定義遷移操作。 (EF 團隊的 Rowan Miller 撰寫了一些關於此 功能的博客文章;第一篇位於以下網址:bit.ly/ZBU0w1。)全部參與者的名單可 以在團隊博客文章《可用的 EF6 RTM》中找到,網址是:bit.ly/1gmDE6D。

我將在本文中深入探討部分公開度不高的主題,並告訴您詳細介紹其他主題的 現有資源。

MSDN 數據開發者中心的版本歷史記錄頁面 (bit.ly/1gCT0nz) 列出了所有功 能,每項功能提供一兩句詳細信息,部分提供指向更多信息的鏈接。

一切迎刃 而解:性能改進與穩定性

性能是許多軟件項目的軟肋,Entity Framework 從一開始就受到了許多性能 方面的批評。 但是,EF 的每一次迭代都給這個方面帶來了巨大的改進。

對性能影響最大的因素之一是首次使用應用程序進程中上下文時的啟動時間。 但是,我們可以通過多種方法改善啟動時間。 希望您已經從我的文章或其他資源 中了解這些方法,例如以下網址提供的關於性能問題的 MSDN 文章: bit.ly/3D6AiC。

通常影響性能的啟動步驟是映射視圖的生成,EF 會利用此過程創建相關的 SQL,用來查詢模型中的每個實體集。 當應用程序運行時,會利用這些視圖,因 此對於部分查詢而言,EF 不必動態創建 SQL。 無論使用 EF 設計器還是使用 Code First 創建模型,都會進行視圖生成。 為了節省時間,可以預先生成這些 視圖,再將其編譯到應用程序中。

對於大型復雜的模型而言,視圖生成尤其耗時。 EF6 對此過程進行了改進, 使得無論預先生成視圖還是在運行時生成視圖,都能顯著提高速度。 請注意,EF 6.0.0 版本的一項缺陷妨礙了此功能,但是該缺陷在 EF 6.0.1(於同一天發布) 中得到了糾正,(在編寫時)采用通過 NuGet 獲得的默認程序包。 此外,由於 對運行時 EF 使用這些生成視圖的方式進行了改進,因而改善了查詢執行時間。 小模型或簡易模型的視圖生成過去從來不是問題。 但是,許多企業的模型都有數 百個實體,同樣包括繼承、關系和其他復雜問題。 此更改將使這些企業大為受益 。

關於如何使用 Entity Framework 程序集中的 Ngen,請參閱 EF6 發布的公告 博客文章中的另一篇性能筆記,網址是:bit.ly/1gmDE6D。

LINQ Contains 的編譯速度更快 EF 團隊不斷地調整查詢創建方式,該團隊重 點進行的一項更改是如何對使用 LINQ Contains 的查詢進行編輯。 說得更清楚 些,就是提高了編譯進程的性能。 由於生成的 SQL 沒有變化,因此數據庫的查 詢執行不受影響。

SQL Server 數據庫創建 EF6 其中一項穩定性的改進與數據庫創建有關。 Model First 和 Code First 工作流都能為您創建數據庫。 如果該數據庫采用 SQL Server,EF 現在針對 SQL Server 數據庫采用了一項“最佳實踐 ”,即將數據庫的 READ_COMMITTED_SNAPSHOT 設置配置為 ON。 這意味著 在默認情況下,數據庫會在每次更改時都為自己創建一個快照。 在實際數據庫中 執行更新時,會對該快照執行查詢。 我在最近一篇博客文章 “What’s that Read_Committed_Snapshot Transaction Support for EF6 About Anyway?”(Read_Committed_Snapshot 事務究竟支持 EF6 的哪一點?)中對此功能進行了介紹,網址是:bit.ly/14FDpZI。

重用打開連接 最後,消除了一項令人心煩的限制:EF6 可讓您對打開的 DbConnection 執行上下文調用。 在過去,如果您顯式打開一個連接後執行使用 該連接的 EF 命令,或者,如果您試圖重用已被另一個上下文調用打開的連接, 將會引發異常並顯示如下消息,“實體連接只能用關閉的 DbConnection 構 造。”現在,EF6 會非常樂意讓您重用已經打開的連接。

專家增強功能

異步支持 在我 2013 年 3 月的數據點專欄文章“Playing with the EF6 Alpha”(小試 EF6 Alpha)中,我對幾項功能進行了探討(異步查詢 、SaveChanges 和自定義約定)(msdn.microsoft.com/magazine/jj991973)。

異步支持將 .NET 4.5 Await 和 Async 模式引入了 EF 的 LINQ 查詢執行方 法,增加了 FirstAsync、 FirstOrDefaultAsync、SingleAsync、 SingleOrDefaultAsync、ToListAsync、ForEachAsync 等。 如需查看完整列表, 請打開 System.Data.Entity.QueryableExtensions。 DbSet 獲得了 FindAsync ,而 DbContext 獲得了 SaveChangesAsync。 自從該文章發表後,沒有發生太多 變化,您不妨看一下該文章了解詳細情況。 此外,Microsoft 還創建了部分演練 和有趣的詳細規范,您可以從我之前提到的版本歷史頁面獲取這些信息。

自定義代碼約定 在該文章中,我還介紹了自定義 Code First 約定,當然也 是另一項專家功能。 在 Code First 最初版本中 EF 團隊對此進行了開發,但是 由於發布受阻,該團隊被迫對其進行擱置,使得許多開發者非常失望。

假定您要將一個公共映射作為一般規則映射到您的實體或屬性。 現在,您可 以將其定義為一個約定,無需單獨為模型每個實體或屬性指定映射,而且它會被 全面應用到所有實體上。 例如,如果您要用 50 個字符表示數據庫中的每個字符 串屬性,無論您的數據庫提供程序使用何種默認值,您都可以將此規則指定為約 定。 由於約定采用 Code First Fluent API,因此如果您這樣配置映射的話,生 成約定應該會感覺非常熟悉。

modelBuilder.Properties<String>().Configure(p => p.HasMaxLength(50))

現在,此模型的每一個字符串將映射到一個 50 字符的數據庫列。 與 Fluent 或注釋配置一樣,您可以指定屬性或實體的約定,並控制繼承映射。 通過約定來 影響關系是基於模型的約定要處理的一個不太常見且更為復雜的任務。 有關詳細 信息,請訪問 bit.ly/1gAqcMq。 您還可使用約定作為數據注釋。 當 Code First 生成模型時可以使用一個用來執行約定的層次結構。 默認情況下,內置約 定先運行,自定義約定後運行。 但是,您可以強制使自定義約定在內置約定前執 行。 有關示例請參閱“Custom Code First Conventions”(自定義 Code First 約定),網址:bit.ly/14dg0CP。

連接復原 如果在 EF 嘗試執行查詢或保存更改時連接斷開,您現在可以讓 EF 重試。 盡管斷開連接是企業 Intranet 的問題,但是經證明連接復原對於幫助應 用程序與雲連接非常有用。 使用 IDbConnectionStrategy 可以配置重試次數。 EF 中包含的 SQL Server 提供程序用來指定 default:SqlServer­ExecutionStrategy,它會顯示錯誤消息告知調整瞬態連 接引發異常的策略。 另外一個策略 SqlAzureExecutionStrategy 通過微調可以 連接 Windows Azure SQL 數據庫。

最簡單的策略指定方法是使用新的 DbConfiguration 類,使用該類可以很容 易配置特定數據庫提供程序的行為。 以下命令可以讓 EF 針對 SqlClient 使用 SQLAzureExecutionStrategy:

         SetExecutionStrategy (SqlProviderServices.ProviderInvariantName,

 () => new SqlAzureExecutionStrategy());

不僅連接策略可以配置,而且您還可以自己創建策略並根據需要通過編程暫停 使用它們。 EF 團隊成員 Miller 在他的博客文章裡介紹了如何暫停使用,網址 是:bit.ly/14gPM1y。

我利用另一位 EF 團隊成員 Glenn Condron 建議的方法對 SqlAzureExecutionStrategy 進行了測試。 為了觸發此策略尋找的特定瞬態連接 故障錯誤代碼,我利用新的 EF6 命令攔截功能引發了一個瞬態連接錯誤。 然後 我運行了測試,測試結果顯示,當我設置執行策略時,在初次失敗後查詢重試了 五次。 一位開發者對我在博客文章中介紹的此功能有一段非常棒的評論,他說他 的公司已經感受到了此功能帶來的好處 (bit.ly/HaqMA0)。

還有一個非常有趣的算法,可以確保不同線程的重試不會全部同時執行。

共享 DbTransactions 和 DbConnections 我希望到現在您已明白,默認情況 下 EF 始終使用 DbTransaction 對數據庫進行調用。 例如,當調用 SaveChanges 時,首先創建一個 DbTransaction,然後再將第一個命令發送到數 據庫。 EF 隨後向數據庫發送所有必要的插入、更新和刪除命令,並最終提交事 務。 如果一個命令失敗,所有以前執行的命令將進行回滾。

通過啟動 TransactionScope 來包裝 EF 調用和任何其他需要包含在相同事務 中的調用(未必是有關數據庫或 EF 的調用),您始終可以替代默認行為。 現在 ,通過 EF6 的附加功能,可以讓單個 DbTransaction 負責多個數據庫調用。 請 注意,如果您要在事務或分布式事務中增加非數據庫邏輯來調用不同的數據庫, 您仍然需要使用 TransactionScope。

與 EF6 共享 DbTransactions 的關鍵是利用新的 BeginTransaction 方法返 回對當前 DbTransaction 的引用或利用 UseTransaction 方法。

以下代碼所展示的是默認行為:

//code to create two new casinos, "casino1" & "casino2"

var context = new CasinoSlotsModel ();

context.Casinos.AddRange(new[] { casino1, casino2 });

context.SaveChanges();

context.Database.ExecuteSqlCommand

 ("Update Casino.Casinos set rating= " +

(int) casino.Rating)

我的探查器顯示了每個上下文調用所使用的事務,其中一個調用 SaveChanges ,用來觸發兩個插入,一個調用 ExecuteSqlCommand,用來觸發更新,如 圖 1 所示。

圖 1 包裝於自身事務中的獨立上下文調用命令

現在我要修改共享事務的代碼,以此包裝 SaveChanges 和 ExecuteSqlCommand 調用。我要使用新增的 DbContext.Database.BeginTransaction 對 System.Data.Entity.DbContextTransaction 進行顯式實例化處理,需要的話還 會打開一個連接(請記住,盡管 DbContext.Database.Connection 的命令相似, 但卻返回 System.Data.Common.DbTransaction,該事務無法被 EF 命令共享):

          using (var tx = context.Database.BeginTransaction()) {   
  try  {   
    context.SaveChanges();   
    context.Database.ExecuteSqlCommand   
      ("Update Casino.Casinos set rating= " +   
      (int) casino.Rating);   
    tx.Commit();   
  }   
  catch (Exception)  {   
    tx.Rollback();   
  }   
}

圖 2 中可以看到同一事務中包裝的所有命令。

圖 2 單個事務中所有上下文調用的命令

還有一項名為 UseTransaction 的新功能。您可以啟動 DbTransaction,然後 用它來執行 ADO.NET 調用,然後利用 DbContext.Database.UseTransaction 甚 至可以從同一事務中的單獨上下文實例來執行 EF 調用。此示例位於以下網址: bit.ly/1aEMIuX。

由於 EF 現在可以利用已打開的連接創建 EntityConnection(由 ObjectContext 在後台執行),還可以顯式重用打開的連接。同時,上下文不會 關閉不是自己打開的連接。我寫了一個簡單的測試程序,通過它我在執行上下文 調用前打開了一個上下文連接。

          [TestMethod]   
public void ContextCanCreateEntityConnectionWithOpenConnection()   
{   
  using (var context = new CasinoSlotsModel())   
  {   
    context.Database.Connection.Open();   
    Assert.IsNotNull(context.Casinos.ToList());   
  }   
}

執行 ToList 調用時,DbContext 會創建一個 ObjectContext 實例,後者進 而創建一個 EntityConnection。然後,它利用 EntityConnection 打開 DbConnection,並在調用完成返回所有結果後關閉該 DbConnection。在 EF5 中 運行此程序時會導致發生異常(“EntityConnection 只能使用關閉的 DbConnection 進行構造”),但是由於行為發生了變化,它在 EF6 中卻能 成功運行。如果您要進一步控制連接狀態,此更改可以讓您重用連接。規范建議 在以下情況下使用,例如“在不能保證連接的狀態時,共享組件之間的連接 。”

AddRange 和 RemoveRange 如前所述,AddRange 和 RemoveRange 由社區成員 Zorrilla 貢獻。每個方法將可枚舉的單個實體類型作 為自己的參數。在共享 DbTransactions 部分的第一個代碼示例中,我在傳入 Casino 實例數組時使用了 AddRange。

context.Casinos.AddRange(new[] { casino1, casino2 });

由於默認情況下 Entity Framework 在每個添加和刪除方法中調用 DetectChanges,因此這些方法比一次添加或刪除單個對象時執行速度快很多。 如果使用 Range 方法,可以在只調用一次 DetectChanges 的同時處理多個對象 ,從而顯著提高了性能。 我用 5、50、500、5,000 甚至 50,000 個對象對此進 行了測試,至少在我的情形下數組大小沒有限制,速度確實非常之快! 請記住, 此改進只有在使上下文作用於對象時有效,對於 SaveChanges 則無效。 調用 SaveChanges 仍然一次只執行一個數據庫命令。 因此,當您快速將 50,000 個對 象添加到上下文中時,在調用 SaveChanges 時仍然要單獨執行 50,000 個插入命 令,恐怕您在實際系統中是不會這樣做的。

另一個方面,對於在不需要 EF 跟蹤對象的情況下對批量操作的實現支持 (bit.ly/16tMHw4) 及通過一次數據庫調用同時發送多個命令的批量操作的討論由 來已久 (bit.ly/PegT17)。 盡管這兩種功能在初始 EF6 版本中都沒有采用,但 是兩者都非常重要,並計劃在將來版本中采用。

與您的編碼風格沖突較少 在 .NET 中,可以通過重寫 System.Object.Equals 方法來定義系統的等同性規則。 但是,Entity Framework 有自己確定被跟蹤實 體等同性的方法,而且此方法依賴於標識。 如果您已經重寫了 Equals(及 Equals 所依賴的 GetHashCode 方法),您的 Entity Framework 更改行為跟蹤 可能會出現問題。 Petar Paar 在他的博客文章中非常清楚地展示了此問題,網 址:bit.ly/GJcohQ。 為了糾正這個問題,EF6 現在使用自己的 Equals 和 GetHashCode 邏輯來執行更改跟蹤任務,而忽略您可能已編寫的任何自定義 Equals 和 GetHashCode 邏輯。 但是,您仍然可以在自己的域邏輯中顯式調用您 自己的自定義方法。 通過這種方法,這兩種方式就能和諧共處。

如果您非常重視圖形和聚合,可能需要在其他類型中嵌套類型。 但是,Code First 模型生成器無法發現嵌套類型,進而無法在模型中創建實體或復雜類型。 圖 3 顯示了一個嵌套類型示例:Address。 由於我只會在 Casino 類型中使用 Address,因此我將它嵌套在了 Casino 類中。 由於 Address 本身不需要標識, 因此我還將 Address 創建為域驅動設計 (DDD) 值對象。 (請參閱我 2013 年 10 月的數據點專欄,“Coding for Domain-­Driven Design:Tips for Data-Focused Devs, Part 3”(域驅動設計的編碼:以數據為中心開發的 提示,第 3 部分)詳細了解 DDD 值對象,網址: msdn.microsoft.com/magazine/dn451438。

圖 3 我的含有嵌套 Address 類型的 Casino 類

          public class Casino()   
{   
  //...other Casino properties & logic   
  public Address PhysicalAddress { get; set; }   
  public Address MailingAddress { get; set; }   
  public class Address:ValueObject<Address>   
  {   
    protected Address(){    }   
    public Address(string streetOrPoBox, string city,   
                   string state,string postalCode)   
    { City = city;   
      State = state;   
      PostalCode = postalCode;   
      StreetOrPoBox = streetOrPoBox; }   
    public string StreetOrPoBox { get; private set; }   
    public string City { get; private set; }   
    public string State { get; private set; }   
    public string PostalCode { get; private set; }   
  }   
}

我使用 EF Power Tools 獲得了模型的可視化表示,而且在圖 4 中我展示了使用 EF5 和 EF6 時分別得到的 Casino 實體。EF5 沒有 識別出嵌套的類型,並且在模型中未包含 Address 或依賴屬性 (PhysicalAddress 和 MailingAddress)。但是,EF6 能夠檢測到嵌套的類型, 可以看出模型中表示的 Address 字段。

查看本欄目

查詢和命令攔截 我剛才沒有提到 CustomDbConfiguration 對 AddInterceptor 的使用。DbConfiguration 在 IDbDependencyResolvers 中 能做的不止是推送。EF6 的另一項新功能是能夠攔截查詢和命令。在攔截查詢和 命令的同時,您可以訪問即將發送至數據庫的生成 SQL 及這些命令返回的結果。 使用此信息可以記錄 SQL 命令甚至修改它們,並告訴 EF 使用更新的命令。盡管 我非常喜歡使用此功能,我還是想留出些空間,建議您閱讀 Arthur Vickers 介 紹此功能的三章博客系列中的第 3 章:“EF6 SQL Logging – Part 3:Interception building blocks”(EF6 SQL 日志記錄 — 第 3 章 :攔截構建基塊)(bit.ly/19om5du),其中有指向第 1 章(“Simple Logging”(簡單日志記錄))和第 2 章(“Changing the content/formatting”(更改內容/格式))的鏈接。

自定義 EF 復數化 在討論自定義 EF 復數化的功能之前, 我要確切地知道您是否了解其默認行為。EF 利用內部復數化服務處理三項任務:

在 Database First 中,它要確保實體采用單數名稱。因此,如果數據庫表的 名稱是 People,在模型中它會變成 Person。

在 Database 或 Model First 的 EF 設計器中,它會根據實體名稱創建復數 EntitySet 名稱(DbSets 的基礎)。例如,服務會確保 Person 實體的 EntitySet 名稱是 People。如果您使用 Database First 創建模型的話,它不會 簡單地使用表名稱。

由於在 Code First 中 DbSets 采用顯式命名,EF 會利用該服務推導出表名 稱。如果開始時使用的類名稱為 Person,約定會認為數據庫表的名稱是 People 。

該服務的作用不是作為拼寫字典(可以提供自定義拼寫的文本列表)。它使用 的是內部規則。除了偶爾出現異常外(最初我非常喜歡 Rhinoceros 這個實體名 稱),該服務最大的問題是規則采用英語。

Zorrilla 為 EF6 創建了 IPluralizationService 接口以便您添加自己的邏 輯。創建自定義服務後,可以按先前所示使用 DbConfiguration 將其插入。

目前,此自定義只能使用前面列表中的第三種情形:Code First 推導表名稱 。從最初的 EF6 版本開始,該自定義不能應用到設計器上。

有兩種使用該服務的方式。開始先使用基本服務 — EF 中的 EnglishPluralizationService 或由其他人已經生成的服務 — 然後重寫 Singularize 或 Pluralize 方法,添加您自己的規則。此外,還可以在 CustomPluralizationEntry 類中指定一對單詞,然後將該類附加到現有服務。 Zorrilla 在他的博客文章中介紹了 CustomPluralizationEntry (bit.ly/161JrD6)。

請留意未來的數據點專欄,我會在該專欄中介紹添加復數化規則的示例(不僅 是單詞對),並展示對於 Code First 數據庫映射的影響。

Code First 的更多好處

有幾項針對 Code First 的新功能我還沒有介紹,特別是 Code First 遷移。 由於空間的關系,在此我先對它們進行概括介紹,再在 2014 年 1 月的數據點專 欄中深入介紹它們:

能夠創建遷移腳本,用來檢查哪些服務已經運行,以便能夠從任何遷移點修復 數據庫。

提高對 Migrations_History 表的控制,以適應不同的數據庫提供程序。

能夠指定數據庫映射的默認架構,無需始終默認為 dbo。

能夠通過遷移處理針對同一數據庫的不同 DbContext。

ModelBuilder 能夠一次性添加多個 EntityTypeConfiguration,無需每個都 使用一個代碼行。

盡快使用專家!

在我看來,EF6 最需要銘記的一點是在 EF 現有功能的基礎上增加了許多很好 的功能。如果您要將項目從 EF5 遷移到 EF6,需要注意部分命名空間的變化。關 於此遷移方法,團隊在以下網址提供了詳細的說明:bit.ly/17eCB4U。除此之外 ,對於使用 EF6 應該充滿信心,它是通過 NuGet 分發的 Entity Framework 的 最新穩定版本。即使您不想馬上使用任何一項專家功能,請記住您仍會從本文前 面介紹的性能提高中獲得益處。但我對於專家功能最感興奮,非常感謝將這些功 能也添加到 EF6 中的社區開發者。

EF 將繼續進行演變。盡管 EF6 第一版的發布時間與 Visual Studio 2013 的 發布時間恰好一致,但是 EF 6.1 和更高版本已經處於開發階段。您可以在 CodePlex 網站上關注它們的進度。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved