Entity Framework 5.0 Code First全面學習

 

目錄(?)[+]

 

不貼圖片了，太累。

Code First 約定

藉助 CodeFirst，可經過使用 C# 或Visual Basic .NET 類來描述模型。模型的基本形狀可經過約定來檢測。約定是規則集，用於在使用 Code First 時基於類定義自動配置概念模型。約定是在 System.Data.Entity.ModelConfiguration.Conventions 命名空間中定義的。

可經過使用數據註釋或Fluent API 進一步配置模型。優先級是經過 Fluent API 進行配置，而後是經過數據註釋，再次是經過約定。

API 文檔中提供了 Code First 約定的詳細列表。本主題概述 Code First 使用的約定。

類型發現

當使用 CodeFirst 開發時，一般是從編寫用來定義概念（域）模型的 .NET類開始。除了定義類以外，還須要讓 DbContext 知道模型中要包含哪些類。爲此，須要定義一個上下文類，此類派生自 DbContext 並公開須要成爲模型一部分的類型的 DbSet 屬性。Code First 將包含這些類型，還將包含任何引用類型，即便這些引用類型是在不一樣的程序集中定義的也是如此。

若是類型存在於繼承層次結構中，則爲基類定義 DbSet 屬性就足夠了，若是派生類型位於與基類相同的程序集中，則自動包含這些派生類型。

在下面的示例中，僅對SchoolEntities 類定義一個DbSet 屬性 (Departments)。CodeFirst 使用此屬性來發現幷包含任何引用類型。

publicclass SchoolEntities: DbContext

{

  public DbSet<Department>Departments { get; set;}

}

 

publicclass Department

{

  // Primary key

  public int DepartmentID { get;set; }

  public string Name { get; set; }

 

  // Navigationproperty

  public virtual ICollection<Course> Courses { get;set; }

}

 

publicclass Course

{

  // Primary key

  public int CourseID { get; set; }

 

  public string Title { get; set; }

  public int Credits { get; set; }

 

  // Foreign key

  public int DepartmentID { get;set; }

 

  // Navigationproperties

  public virtual DepartmentDepartment { get; set;}

}

 

publicpartial class OnlineCourse : Course

{

  public string URL { get; set; }

}

 

publicpartial class OnsiteCourse : Course

{

  public string Location { get;set; }

  public string Days { get; set; }

  publicSystem.DateTime Time { get; set; }

}

若是要從模型排除類型，請使用 NotMapped 特性或DbModelBuilder.Ignore

主鍵約定

若是類的屬性名爲「ID」（不區分大小寫）或類名的後面跟有「ID」，則 Code First 會推斷該屬性是主鍵。若是主鍵屬性的類型爲數值或 GUID，則將其配置爲標識列。

publicclass Department

{

  // Primary key

  public int DepartmentID { get;set; }

}

 

關係約定

實體框架中的導航屬性提供了一種在兩個實體類型之間導航關係的方法。針對對象參與到其中的每一個關係，各對象都可以具備導航屬性。使用導航屬性，能夠在兩個方向上導航和管理關係，返回引用對象（若是多重性爲一或者零或一）或集合（若是多重性爲多）。Code First 根據針對類型定義的導航屬性來推斷關係。

除導航屬性外，建議還要包括表示依賴對象的類型的外鍵屬性。任何數據類型與主體主鍵屬性相同、遵循如下一種格式的屬性都表示關係的外鍵：「<導航屬性名稱><主體主鍵屬性>」、「<主體類名><主鍵屬性名稱>」或「<主體主鍵屬性名稱>」。若是找到多個匹配項，則優先級符合上面列出的順序。外鍵檢測不區分大小寫。在檢測外鍵屬性時，Code First 基於外鍵的可空性推斷關係的多重性。若是屬性能夠爲 Null，則將關係註冊爲可選關係；不然，將關係註冊爲必需關係。

若是依賴實體上的外鍵不能爲 Null，則 CodeFirst 對關係設置級聯刪除。若是依賴實體上的外鍵能夠爲 Null，則Code First 不對關係設置級聯刪除，而且在刪除主體時，會將該外鍵設置爲 Null。經過使用 Fluent API，能夠覆蓋由約定檢測的多重性和級聯刪除行爲。

publicclass Department

{

  // Primary key

  public int DepartmentID { get;set; }

  public string Name { get; set; }

 

  // Navigationproperty

  public virtual ICollection<Course> Courses { get;set; }

}

 

publicclass Course

{

  // Primary key

  public int CourseID { get; set; }

 

  public string Title { get; set; }

  public int Credits { get; set; }

 

  // Foreign key

  public int DepartmentID { get;set; }

 

  // Navigationproperties

  public virtual DepartmentDepartment { get; set;}

}

 

在下面的示例中，導航屬性和外鍵用於定義 Department 類與Course 類之間的關係。

注意：若是相同類型間有多個關係（例如，假設定義 Person 和Book 類，其中，Person 包含ReviewedBooks 和AuthoredBooks 導航屬性，而Book 類包含 Author 和Reviewer 導航屬性），則須要使用數據註釋或 Fluent API 手動配置關係。

複雜類型約定

當 CodeFirst 發現沒法推斷主鍵以及未經過數據註釋或 Fluent API 註冊主鍵的類時，類型會自動註冊爲複雜類型。複雜類型檢測還要求類型不具備引用實體類型的屬性，而且未被其餘類型的集合屬性引用。對於如下類定義，Code First 推斷Details 是複雜類型，由於它沒有主鍵。

publicpartial class OnsiteCourse : Course

{

  publicOnsiteCourse()

  {

    Details = newDetails();

  }

 

  public Details Details { get;set; }

}

 

publicclass Details

{

  publicSystem.DateTime Time { get; set; }

  public string Location { get;set; }

  public string Days { get; set; }

}

 

鏈接字符串約定

默認配置

若是您尚未在應用程序中進行任何其餘配置，則對 DbContext 調用無參數構造函數將會致使 DbContext 使用按約定建立的數據庫鏈接在 Code First 模式下運行。例如：

namespaceDemo.EF

{

  public class BloggingContext: DbContext

  {

    publicBloggingContext()

    // C# will callbase class parameterless constructor by default

    {

    }

  }

}

在此示例中，DbContext使用派生上下文類 Demo.EF.BloggingContext 的命名空間限定名稱做爲數據庫名稱，並使用 SQL Express 或 LocalDb 爲此數據庫建立鏈接字符串。若是同時安裝了這兩個數據庫，將使用 SQL Express。

默認狀況下，VisualStudio 2010 包含 SQLExpress，VisualStudio 2012 包含LocalDb。安裝期間，EntityFrameworkNuGet 包會檢查哪一個數據庫服務器可用。隨後 NuGet 包將設置按約定建立鏈接時 Code First 所使用的默認數據庫服務器，以此更新配置文件。若是 SQL Express 正在運行，將使用它。若是 SQL Express 不可用，則 LocalDb 將註冊爲默認數據庫。若是配置文件已包含默認鏈接工廠設置，則不會更改該文件。

指定數據庫名稱

若是您還沒有在應用程序中進行任何其餘配置，在經過要使用的數據庫名稱對 DbContext 調用字符串構造函數時，將會致使 DbContext 使用按約定建立的與該名稱數據庫的鏈接在 Code First 模式下運行。例如：

namespaceDemo.EF

{

  public class BloggingContext: DbContext

  {

    public BloggingContext()

      : base("BloggingDatabase")

    {

    }

  }

}

在此示例中，DbContext使用「BloggingDatabase」做爲數據庫名稱，並使用 SQL Express（隨Visual Studio 2010 安裝）或LocalDb（隨Visual Studio 2012 安裝）爲此數據庫建立鏈接字符串。若是同時安裝了這兩個數據庫，將使用 SQL Express。

指定鏈接字符串

能夠選擇將鏈接字符串放入 app.config 或web.config 文件中。例如：

<configuration>

  <connectionStrings>

    <addname="BloggingCompactDatabase"

         providerName="System.Data.SqlServerCe.4.0"

         connectionString="Data Source=Blogging.sdf"/>

  </connectionStrings>

</configuration>

這是一種指示 DbContext 使用數據庫服務器而非 SQL Express 或LocalDb 的簡單方法 — 上例指定了 SQL Server Compact Edition 數據庫。

若是鏈接字符串的名稱與上下文的名稱（帶或不帶命名空間限定）相同，則使用無參數構造函數時 DbContext 會找到該鏈接字符串。若是鏈接字符串名稱與上下文名稱不一樣，則可經過將鏈接字符串名稱傳遞給 DbContext 構造函數，指示 DbContext 在 CodeFirst 模式下使用此鏈接。例如：

publicclass BloggingContext: DbContext

{

  publicBloggingContext()

    : base("BloggingCompactDatabase")

  {

  }

}

或者，也能夠對傳遞給DbContext 構造函數的字符串使用 「name=<鏈接字符串名稱>」格式。例如：

publicclass BloggingContext: DbContext

{

  publicBloggingContext()

    : base("name=BloggingCompactDatabase")

  {

  }

}

使用此形式能夠明確要求在配置文件中查找鏈接字符串。若是未找到具備給定名稱的鏈接字符串，則將引起異常。

數據庫初始化策略：

數據庫建立是由策略來控制的，有以下四種策略：

1.       CreateDatabaseIfNotExists：這是默認的策略。若是數據庫不存在，那麼就建立數據庫。可是若是數據庫存在了，並且實體發生了變化，就會出現異常。

2.       DropCreateDatabaseIfModelChanges：此策略代表，若是模型變化了，數據庫就會被從新建立，原來的數據庫被刪除掉了。

3.       DropCreateDatabaseAlways：此策略表示，每次運行程序都會從新建立數據庫，這在開發和調試的時候很是有用。

4.       自定製數據庫策略：能夠本身實現IDatabaseInitializer來建立本身的策略。或者從已有的實現了IDatabaseInitializer接口的類派生。

以下示例顯示瞭如何應用數據庫建立策略：

public class UserManContext : DbContext

{

    public UserManContext()

        : base("USMDBConnectionString")

    {           

        Database.SetInitializer<UserManContext>(new CreateDatabaseIfNotExists<UserManContext>());

    }   

}

下面的代碼建立了一個自定義策略，什麼也沒有作，可是咱們能夠在Seed方法裏添加咱們的種子數據。

public class USMDBInitializer : DropCreateDatabaseAlways<UserManContext>

{

    protected override void Seed(UserManContext context)

    {

        base.Seed(context);

    }

}

雖然EF提供了在配置文件中配置策略的方法，以下所示：

<appSettings>

    <addkey="DatabaseInitializerForType EFCodeFirstSample.UserManContext, EFCodeFirstSample"

        value="System.Data.Entity.DropCreateDatabaseAlways`1[[EFCodeFirstSample.UserManContext,EFCodeFirstSample]], EntityFramework" />

  </appSettings>

Key必須以DatabaseInitializerForType開始，後邊加空格，以後是context類的全名稱，包括帶命名空間的類名和所在的程序集名。Value是策略的全名稱。能夠看見key和value都很是難讀，還不如本身寫配置來的好。

若是不想使用策略，就能夠關閉策略，特別是默認策略。關閉策略的代碼以下：

public class UserManContext : DbContext

{

    public UserManContext()

        : base("USMDBConnectionString")

    {           

        Database.SetInitializer<UserManContext>(null);

    }

}

還能夠在配置文件中關閉策略，以下：

<addkey="DatabaseInitializerForTypeEFCodeFirstSample.UserManContext, EFCodeFirstSample"

        value="Disabled" />

 

爲數據庫添加種子數據

上面提升能夠在自定義數據庫初始化策略中添加種子數據，下面的示例說明如何添加種子數據：

public class USMDBInitializer : DropCreateDatabaseAlways<UserManContext>

{

    protected override void Seed(UserManContext context)

    {

        User admin = new User();

        admin.Name = "admin";

        admin.DisplayName = "Administrator";

        admin.Status = 1;

        admin.LastModDate= DateTime.Now;

        context.Users.Add(admin);

 

        base.Seed(context);

    }

}

須要注意的是日期字段，數據庫中的日期範圍小於.NET中的日期範圍，因此必須給一個合適的值，像DateTime.MinValue這樣的值沒法存儲到數據庫中。能夠參考SqlDateTime類型來肯定Sql數據庫支持的時間範圍。

移除約定

能夠移除在System.Data.Entity.ModelConfiguration.Conventions 命名空間中定義的任何約定。下面的示例移除 PluralizingTableNameConvention。

publicclass SchoolEntities: DbContext

{

  protected override voidOnModelCreating(DbModelBuilder modelBuilder)

  {

    // Configure CodeFirst to ignore PluralizingTableName convention

    // If you keepthis convention, the generated tables

    // will havepluralized names.

    modelBuilder.Conventions.Remove<PluralizingTableNameConvention>();

  }

}

可插入約定

可插入（自定義）約定目前不受支持，正在針對 EF6 進行開發。

Code First 數據註釋

經過實體框架Code First，可使用您本身的域類表示 EF 執行查詢、更改跟蹤和更新函數所依賴的模型。Code First 利用稱爲「約定先於配置」的編程模式。這就是說，Code First 將假定您的類聽從 EF 所使用的約定。在這種狀況下，EF 將可以找出本身工做所需的詳細信息。可是，若是您的類不遵照這些約定，則能夠向類中添加配置，以向 EF 提供它須要的信息。

Code First 爲您提供了兩種方法來向類中添加這些配置。一種方法是使用名爲 DataAnnotations 的簡單特性，另外一種方法是使用 Code First 的Fluent API，該 API 向您提供了在代碼中以命令方式描述配置的方法。

本文重點介紹如何使用DataAnnotations（在System.ComponentModel.DataAnnotations 命名空間中）對類進行配置，着重講述經常使用的配置。不少 .NET 應用程序（如 ASP.NET MVC）都可以理解DataAnnotations，它容許這些應用程序對客戶端驗證使用相同的註釋。

我將經過Blog 和 Post 這兩個簡單的類來講明 Code First DataAnnotations。

publicclass Blog

{

  public int Id { get; set; }

  public string Title { get; set; }

  public string BloggerName { get;set; }

  public virtual ICollection<Post> Posts { get;set; }

}

 

publicclass Post

{

  public int Id { get; set; }

  public string Title { get; set; }

  public DateTime DateCreated { get;set; }

  public string Content { get;set; }

  public int BlogId { get; set; }

  public ICollection<Comment>Comments { get; set;}

}

Blog 和 Post 類自己就遵照 Code First 約定，無需調整便可讓EF 與之共同使用。但您也可使用註釋向 EF 提供有關類以及類所映射到的數據庫的更多信息。

 

鍵

實體框架依賴於每一個具備鍵值的實體，它使用鍵值來跟蹤實體。Code First 依賴的一個約定是它在每個 Code First 類中以何種方式表示哪個屬性是鍵。該約定是查找名爲「Id」或類名與「Id」組合在一塊兒（如「BlogId」）的屬性。該屬性將映射到數據庫中的主鍵列。

Blog 和 Post 類都遵照此約定。但若是它們不遵照呢？若是 Blog 使用名稱 PrimaryTrackingKey，甚至使用 foo 呢？若是Code First 找不到符合此約定的屬性，它將引起異常，由於實體框架要求必需要有一個鍵屬性。您可使用鍵註釋來指定要將哪個屬性用做 EntityKey。

publicclass Blog

{

  [Key]

  public int PrimaryTrackingKey { get;set; }

  public string Title { get; set; }

  public string BloggerName { get;set; }

  public virtual ICollection<Post> Posts { get;set; }

}

若是您在使用Code First 的數據庫生成功能，則Blog 表將具備名爲 PrimaryTrackingKey 的主鍵列，該列默認狀況下還定義爲 Identity。

 

 

必需

Required 註釋告訴 EF 某一個特定屬性是必需的。

在 Title 屬性中添加 Required 將強制 EF（和 MVC）確保該屬性中包含數據。

[Required]

publicstring Title { get;set; }

Required 特性將使被映射的屬性不可爲空來影響生成的數據庫。請注意，Title 字段已經更改成「not null」。

 

MaxLength 和MinLength

使用MaxLength 和MinLength 特性，您能夠就像對Required 那樣指定其餘屬性驗證。

下面是具備長度要求的BloggerName。該示例也說明如何組合特性。

[MaxLength(10), MinLength(5)]

publicstring BloggerName { get;set; }

 

MaxLength 註釋將經過把屬性長度設置爲 10 來影響數據庫。MinLength屬性不會對數據庫產生影響。

 

NotMapped

Code First 約定指示具備受支持數據類型的每一個屬性都要在數據庫中有表示。但在您的應用程序中並不老是如此。例如，您能夠在 Blog 類中使用一個屬性來基於 Title 和BloggerName 字段建立代碼。該屬性能夠動態建立，無需存儲。您可使用 NotMapped 註釋來標記不映射到數據庫的全部屬性，以下面的 BlogCode 屬性。

[NotMapped]

publicstring BlogCode

{

  get

  {

    returnTitle.Substring(0, 1) + ":" +BloggerName.Substring(0, 1);

  }

}

ComplexType

跨一組類描述域實體，而後將這些類分層以描述一個完整實體的狀況並很多見。例如，您能夠向模型中添加一個名爲 BlogDetails 的類。

publicclass BlogDetails

{

  public DateTime? DateCreated { get;set; }

 

  [MaxLength(250)]

  public string Description { get;set; }

}

請注意，BlogDetails 沒有任何鍵屬性類型。在域驅動的設計中，BlogDetails 稱爲值對象。實體框架將值對象稱爲複雜類型。複雜類型不能自行跟蹤。

 

可是 BlogDetails 做爲 Blog 類中的一個屬性，將做爲 Blog 對象的一部分被跟蹤。爲了讓 Code First 認識到這一點，您必須將 BlogDetails 類標記爲 ComplexType。

[ComplexType]

publicclass BlogDetails

{

  public DateTime? DateCreated { get;set; }

  [MaxLength(250)]

  public string Description { get;set; }

}

如今，您能夠在Blog 類中添加一個屬性來表示該博客的 BlogDetails。

    public BlogDetails BlogDetail { get; set; }

在數據庫中，Blog表將包含該博客的全部屬性，包括在其 BlogDetail 屬性中所含的屬性。默認狀況下，每一個屬性都將添加複雜類型名稱前綴 BlogDetail。

 

另外，有趣的是，雖然DateCreated 屬性在類中定義爲不可爲空的 DateTime，但相關數據庫字段是可爲空的。若是想影響數據庫架構，則必須使用 Required 註釋。

ConcurrencyCheck

ConcurrencyCheck 註釋可用於標記要在用戶編輯或刪除實體時用於在數據庫中進行併發檢查的一個或多個屬性。若是以前使用 EF 設計器，則這等同於將屬性的 ConcurrencyMode 設置爲 Fixed。

如今讓咱們將ConcurrencyCheck 添加到BloggerName 屬性，看看它如何工做。

[ConcurrencyCheck, MaxLength(10),MinLength(5)]   

publicstring BloggerName { get;set; }

調用SaveChanges 時，由於BloggerName 字段上具備ConcurrencyCheck 註釋，因此在更新中將使用該屬性的初始值。該命令將嘗試經過同時依據鍵值和 BloggerName 的初始值進行篩選來查找正確的行。下面是發送到數據庫的 UPDATE 命令的關鍵部分，在其中您能夠看到該命令將更新 PrimaryTrackingKey 爲 1 且BloggerName 爲「Julie」（這是從數據庫中檢索到該博客時的初始值）的行。

where (([PrimaryTrackingKey]= @4) and([BloggerName] = @5))

@4=1,@5=N'Julie'

若是在此期間有人更改了該博客的博主姓名，則此更新將失敗，並引起 DbUpdateConcurrencyException 而且須要處理該異常。

TimeStamp

使用rowversion 或timestamp 字段來進行併發檢查更爲常見。可是比起使用 ConcurrencyCheck 註釋，只要屬性類型爲字節數組，則不如使用更爲具體的 TimeStamp 註釋。Code First 將Timestamp 屬性與ConcurrencyCheck 屬性同等對待，但它還將確保 Code First 生成的數據庫字段是不可爲空的。在一個指定類中，只能有一個 timestamp 屬性。

將如下屬性添加到Blog 類：

[Timestamp]

publicByte[] TimeStamp { get;set; }

這樣，CodeFirst 將在數據庫表中建立一個不可爲空的 Timestamp 列。

 

表和列

若是您讓Code First 建立數據庫，則可能但願更改它建立的表和列的名稱。也能夠將 Code First 用於現有數據庫。可是域中的類和屬性的名稱並不老是與數據庫中表和列的名稱相匹配。

個人類名爲Blog，按照約定，Code First 將假定此類映射到名爲 Blogs 的表。若是不是這樣，您能夠用 Table 特性指定該表的名稱。舉例來講，下面的註釋指定表名稱爲 InternalBlogs，同時指定了schema，默認的schema就是dbo。

[Table("InternalBlogs",Schema="dbo")]

publicclass Blog

 

Column 註釋更適於用來指定被映射列的特性。您能夠規定名稱、數據類型甚至列出如今表中的順序。下面是 Column 特性的示例。

[Column("BlogDescription",TypeName = "ntext")]

publicString Description { get; set; }

 

下面是從新生成後的表。表名稱已更改成 InternalBlogs，複雜類型的 Description 列如今是BlogDescription。由於該名稱在註釋中指定，Code First 不會使用以複雜類型名稱做爲列名開頭的約定。

 

DatabaseGenerated

一個重要的數據庫功能是可使用計算屬性。若是您將 Code First 類映射到包含計算列的表，則您可能不想讓實體框架嘗試更新這些列。可是在插入或更新數據後，您的確須要 EF 從數據庫中返回這些值。您可使用 DatabaseGenerated 註釋與 Computed 枚舉一塊兒在您的類中標註這些屬性。其餘枚舉爲 None 和Identity。

[DatabaseGenerated(DatabaseGeneratedOption.Computed)]

publicDateTime DateCreated { get; set; }

 

當 Code First生成數據庫時，您能夠對 byte 或timestamp 列使用此標記，不然您只應該在指向現有數據庫時使用，由於 Code First 將不能肯定計算列的公式。

您閱讀過以上內容，知道默認狀況下，整數鍵屬性將成爲數據庫中的標識鍵。這與將 DatabaseGenerated 設置爲 DatabaseGenerationOption.Identity 是同樣的。若是不但願它成爲標識鍵，則能夠將該值設置爲 DatabaseGenerationOption.None。

關係特性：InverseProperty和ForeignKey

Code First 約定將在您的模型中處理最經常使用的關係，可是在某些狀況下它須要幫助。

在 Blog 類中更改鍵屬性的名稱形成它與 Post 的關係出現問題。

生成數據庫時，CodeFirst 會在 Post 類中看到 BlogId 屬性並識別出該屬性，按照約定，它與類名加「Id」匹配，並做爲 Blog 類的外鍵。可是在此Blog 類中沒有 BlogId 屬性。解決方法是，在 Post 中建立一個導航屬性，並使用 Foreign DataAnnotation 來幫助 CodeFirst 瞭解如何在兩個類之間建立關係（那就是使用 Post.BlogId 屬性）以及如何在數據庫中指定約束。

publicclass Post

{

  public int Id { get; set; }

  public string Title { get; set; }

  public DateTime DateCreated { get;set; }

  public string Content { get;set; }

  public int BlogId { get; set; }

  [ForeignKey("BlogId")]

  public Blog Blog { get; set; }

}

數據庫中的約束顯示InternalBlogs.PrimaryTrackingKey 與Posts.BlogId 之間的關係。

 

 

類之間存在多個關係時，將使用 InverseProperty。

在 Post 類中，您可能須要跟蹤是誰撰寫了博客文章以及誰編輯了它。下面是 Post 類的兩個新的導航屬性。

publicPerson CreatedBy { get;set; }

publicPerson UpdatedBy { get;set; }

 

您還須要在這些屬性引用的 Person 類中添加內容。Person類具備返回到 Post 的導航屬性，一個屬性指向該用戶撰寫的全部文章，一個屬性指向該用戶更新的全部文章。

publicclass Person

{

  public int Id { get; set; }

  public string Name { get; set; }

  public List<Post>PostsWritten { get; set;}

  public List<Post>PostsUpdated { get; set;}

}

Code First 不能自行使這兩個類中的屬性匹配。Posts 的數據庫表應該有一個表示 CreatedBy 人員的外鍵，有一個表示 UpdatedBy 人員的外鍵，可是 Code First 將建立四個外鍵屬性：Person_Id、Person_Id一、CreatedBy_Id 和UpdatedBy_Id。(針對每一個導航屬性建立一個外鍵)

 

要解決這些問題，您可使用 InverseProperty 註釋來指定這些屬性的匹配。

[InverseProperty("CreatedBy")]

publicList<Post>PostsWritten { get; set;}

 

[InverseProperty("UpdatedBy")]

publicList<Post>PostsUpdated { get; set;}

 

由於Person 中的PostsWritten 屬性知道這指的是Post 類型，因此它將與 Post.CreatedBy 創建關係。一樣，PostsUpdated 也將與 Post.UpdatedBy 創建關係。Code First 不會建立額外的外鍵。

 

總結

DataAnnotations 不只可用於在 Code First 類中描述客戶端和服務器端驗證，還讓您可以增強甚至更正 Code First 將基於其約定對您的類所做的假設。使用 DataAnnotations，您不只可以推進數據庫架構生成，還能將 Code First 類映射到預先存在的數據庫。

雖然它們都很是靈活，但請記住，DataAnnotations 只提供您常常須要對 Code First 類進行的配置更改。要爲一些邊緣狀況配置類，則應該採用另外一種替代配置機制，那就是 Code First 的Fluent API。

使用Fluent API 配置/映射屬性和類型

簡介

一般經過重寫派生DbContext 上的OnModelCreating 方法來訪問Code First Fluent API。如下示例旨在顯示如何使用 Fluent API 執行各類任務，您能夠將代碼複製出來並進行自定義，使之適用於您的模型。

屬性映射

Property 方法用於爲每一個屬於實體或複雜類型的屬性配置特性。Property 方法用於獲取給定屬性的配置對象。配置對象上的選項特定於要配置的類型；例如，IsUnicode 只能用於字符串屬性。

配置主鍵

要顯式將某個屬性設置爲主鍵，可以使用 HasKey 方法。在如下示例中，使用了 HasKey 方法對 OfficeAssignment 類型配置 InstructorID 主鍵。

modelBuilder.Entity<OfficeAssignment>().HasKey(t =>t.InstructorID);

 

配置組合主鍵

如下示例配置要做爲Department 類型的組合主鍵的DepartmentID 和 Name 屬性。

modelBuilder.Entity<Department>().HasKey(t => new { t.DepartmentID, t.Name });

 

關閉數值主鍵的標識

如下示例將DepartmentID 屬性設置爲System.ComponentModel.DataAnnotations.DatabaseGeneratedOption.None，以指示該值不禁數據庫生成。

modelBuilder.Entity<Department>().Property(t =>t.DepartmentID).HasDatabaseGeneratedOption(DatabaseGeneratedOption.None);

 

指定屬性的最大長度

在如下示例中，Name屬性不該超過 50 個字符。若是其值超過 50 個字符，則出現 DbEntityValidationException 異常。若是 Code First 基於此模型建立數據庫，它還會將 Name 列的最大長度設置爲50 個字符。

modelBuilder.Entity<Department>().Property(t =>t.Name).HasMaxLength(50);

 

將屬性配置爲必需

在下面的示例中，Name屬性是必需的。若是不指定 Name，則出現 DbEntityValidationException 異常。若是 Code First 基於此模型建立數據庫，則用於存儲此屬性的列將不可爲空。

modelBuilder.Entity<Department>().Property(t =>t.Name).IsRequired();

 

指定不將CLR 屬性映射到數據庫中的列

如下示例顯示如何指定CLR 類型的屬性不映射到數據庫中的列。

modelBuilder.Entity<Department>().Ignore(t => t.Budget);

 

將CLR 屬性映射到數據庫中的特定列

如下示例將Name CLR 屬性映射到DepartmentName 數據庫列。

modelBuilder.Entity<Department>().Property(t =>t.Name).HasColumnName("DepartmentName");

 

重命名模型中未定義的外鍵

若是您選擇不對CLR 類型定義外鍵，但但願指定它在數據庫中應使用的名稱，請編碼以下：

modelBuilder.Entity<Course>()

        .HasRequired(c => c.Department)

        .WithMany(t => t.Courses)

        .Map(m => m.MapKey("ChangedDepartmentID"));

 

配置字符串屬性是否支持Unicode 內容

默認狀況下，字符串爲Unicode（SQLServer 中的nvarchar）。您可使用IsUnicode 方法指定字符串應爲varchar 類型。

modelBuilder.Entity<Department>()

        .Property(t => t.Name)

        .IsUnicode(false);

 

配置數據庫列的數據類型

HasColumnType 方法支持映射到相同基本類型的不一樣表示。使用此方法並不支持在運行時執行任何數據轉換。請注意，IsUnicode 是將列設置爲 varchar 的首選方法，由於它與數據庫無關。

modelBuilder.Entity<Department>()

        .Property(p => p.Name)

        .HasColumnType("varchar");

 

配置複雜類型的屬性

對複雜類型配置標量屬性有兩種方法。

能夠對ComplexTypeConfiguration 調用Property。

modelBuilder.ComplexType<Details>()

        .Property(t => t.Location)

        .HasMaxLength(20);

 

也可使用點表示法訪問複雜類型的屬性。

modelBuilder.Entity<OnsiteCourse>()

        .Property(t => t.Details.Location)

        .HasMaxLength(20);

 

將屬性配置爲用做樂觀併發令牌

要指定實體中的某個屬性表示併發令牌，可以使用 ConcurrencyCheck 特性或 IsConcurrencyToken 方法。

modelBuilder.Entity<OfficeAssignment>()

        .Property(t => t.Timestamp)

        .IsConcurrencyToken();

 

也可使用IsRowVersion 方法將屬性配置爲數據庫中的行版本。將屬性設置爲行版本會自動將它配置爲樂觀併發令牌。

modelBuilder.Entity<OfficeAssignment>()

        .Property(t => t.Timestamp)

        .IsRowVersion();

 

類型映射

將類指定爲複雜類型

按約定，沒有指定主鍵的類型將被視爲複雜類型。在一些狀況下，Code First 不會檢測複雜類型（例如，若是您有名爲「ID」的屬性，但不想將它用做主鍵）。在此類狀況下，您將使用 Fluent API 顯式指定某類型是複雜類型。

modelBuilder.ComplexType<Details>();

 

指定不將CLR 實體類型映射到數據庫中的表

如下示例顯示如何排除一個 CLR 類型，使之不映射到數據庫中的表。

modelBuilder.Ignore<OnlineCourse>();

 

將CLR 實體類型映射到數據庫中的特定表

Department 的全部屬性都將映射到名爲 t_ Department 的表中的列。

modelBuilder.Entity<Department>().ToTable("t_Department");

 

您也能夠這樣指定架構名稱：

modelBuilder.Entity<Department>().ToTable("t_Department", "school");

 

映射「每一個層次結構一張表(TPH)」繼承

在 TPH 映射情形下，繼承層次結構中的全部類型都將映射到同一個表。鑑別器列用於標識每行的類型。使用 Code First 建立模型時，TPH 參與繼承層次結構的類型所用的默認策略。默認狀況下，鑑別器列將添加到名爲「Discriminator」的表，且層次結構中每一個類型的 CLR 類型名稱都將用做鑑別器值。可使用 Fluent API 修改默認行爲。

modelBuilder.Entity<Course>()

        .Map<Course>(m=> m.Requires("Type").HasValue("Course"))

        .Map<OnsiteCourse>(m=> m.Requires("Type").HasValue("OnsiteCourse"));

 

映射「每一個類型一張表(TPT)」繼承

在 TPT 映射情形下，全部類型分別映射到不一樣的表。僅屬於某個基類型或派生類型的屬性存儲在映射到該類型的一個表中。映射到派生類型的表還會存儲一個將派生表與基表聯接的外鍵。

modelBuilder.Entity<Course>().ToTable("Course");

modelBuilder.Entity<OnsiteCourse>().ToTable("OnsiteCourse");

 

映射「每一個具體類一張表(TPC)」繼承

在 TPC 映射情形下，層次結構中的全部非抽象類型分別映射到不一樣的表。映射到派生類的表與映射到數據庫中基類的表並沒有關係。類的全部屬性（包括繼承屬性）都將映射到相應表的列。

調用MapInheritedProperties 方法來配置每一個派生類型。MapInheritedProperties 將繼承自基類的全部屬性從新映射到派生類的表中的新列。

注意：由於屬於TPC 繼承層次結構的表並不使用同一個主鍵，所以，若是您讓數據庫生成的值具備相同標識種子，則在映射到子類的表中執行插入操做時，會產生重複的實體鍵。要解決此問題，能夠爲每一個表指定不一樣的初始種子值，或關閉主鍵屬性的標識。當使用 Code First 時，標識就是整數鍵屬性的默認值。

modelBuilder.Entity<Course>()

  .Property(c => c.CourseID)

  .HasDatabaseGeneratedOption(DatabaseGeneratedOption.None);

 

modelBuilder.Entity<OnsiteCourse>().Map(m =>

{

  m.MapInheritedProperties();

  m.ToTable("OnsiteCourse");

});

 

modelBuilder.Entity<OnlineCourse>().Map(m =>

{

  m.MapInheritedProperties();

  m.ToTable("OnlineCourse");

});

 

將實體類型的CLR 屬性映射到數據庫中的多個表（實體拆分）

實體拆分容許一個實體類型的屬性分散在多個表中。在如下示例中，Department 實體拆分到兩個表中：Department 和DepartmentDetails。實體拆分經過屢次調用 Map 方法將一部分屬性映射到特定表。

modelBuilder.Entity<Department>()

.Map(m=>

{

  m.Properties(t => new{ t.DepartmentID, t.Name });

  m.ToTable("Department");

})

.Map(m=>

{

  m.Properties(t=> new { t.DepartmentID, t.Administrator,t.StartDate, t.Budget });

  m.ToTable("DepartmentDetails");

 });

 

將多個實體類型映射到數據庫中的一個表（表拆分）

如下示例將使用同一個主鍵的兩個實體類型映射到同一個表。

modelBuilder.Entity<OfficeAssignment>()

  .HasKey(t => t.InstructorID);

modelBuilder.Entity<Instructor>()

    .HasRequired(t => t.OfficeAssignment)

    .WithRequiredPrincipal(t =>t.Instructor);

modelBuilder.Entity<Instructor>().ToTable("Instructor");

modelBuilder.Entity<OfficeAssignment>().ToTable("Instructor");

 

使用FluentAPI配置關係

簡介

使用FluentAPI配置關係的時候，首先要得到一個EntityTypeConfiguration實例，而後使用其上的HasRequired, HasOptional或者 HasMany方法來指定當前實體參與的關係類型。HasRequired 和HasOptional方法須要一個lambda表達式來指定一個導航屬性，HasMany方法須要一個lambda表達式指定一個集合導航屬性。而後可使用WithRequired, WithOptional和WithMany方法來指定反向導航屬性，這些方法有不帶參數的重載用來指定單向導航。

以後還可使用HasForeignKey方法來指定外鍵屬性。

配置【必須-可選】關係（1-0..1）

OfficeAssignment的鍵屬性不符合命名約定，因此須要咱們顯式指定。下面的關係代表，OfficeAssignment的Instructor必須存在，可是Instructor的OfficeAssignment不是必須存在的。

modelBuilder.Entity<OfficeAssignment>()

  .HasKey(t => t.InstructorID);

 

// Map one-to-zero or one relationship

modelBuilder.Entity<OfficeAssignment>()

  .HasRequired(t => t.Instructor)

  .WithOptional(t => t.OfficeAssignment);

配置兩端都是必須的關係（1-1）

大多數狀況下，EF都能推斷哪個類型是依賴項或者是主體項。然而當關系的兩端都是必須的或者都是可選的，那麼EF就不能識別依賴項或者是主體項。若是關係兩端都是必須的，那麼在HasRequired方法後使用WithRequiredPrincipal或者WithRequiredDependent來肯定主體。若是關係兩端都是可選的，那麼在HasRequired方法後使用WithOptionalPrincipal和WithOptionalDependent。

 

modelBuilder.Entity<OfficeAssignment>()

  .HasKey(t => t.InstructorID);

 

modelBuilder.Entity<Instructor>()

  .HasRequired(t => t.OfficeAssignment)

  .WithRequiredPrincipal(t => t.Instructor);

 

配置多對多關係

下面的代碼配置了一個多對多關係，CodeFirst會使用命名約定來建立鏈接表，命名約定會使用Course_CourseID 和 Instructor_InstructorID做爲鏈接表的列。

 

modelBuilder.Entity<Course>()

        .HasMany(t => t.Instructors)

        .WithMany(t => t.Courses);

若是想指定鏈接表的表名和列名，須要使用Map方法，以下：

modelBuilder.Entity<Course>()

        .HasMany(t => t.Instructors)

        .WithMany(t => t.Courses)

        .Map(m =>

        {

          m.ToTable("CourseInstructor");

          m.MapLeftKey("CourseID");

          m.MapRightKey("InstructorID");

        });

 

配置單向導航屬

所謂單向導航屬性指的是隻在關係的一端定義了導航屬性。按照約定，CodeFirst將單向導航理解爲一對多關係，若是須要一對一的單向導航屬性，須要使用以下方法：

modelBuilder.Entity<OfficeAssignment>()

  .HasKey(t => t.InstructorID);

 

modelBuilder.Entity<Instructor>()

  .HasRequired(t => t.OfficeAssignment)

  .WithRequiredPrincipal();

 

啓用級聯刪除

使用WillCascadeOnDelete方法來配置關係是否容許級聯刪除。若是外鍵是不可空的，CodeFirst默認會設置級聯刪除；不然，不會設置級聯刪除，當主體被刪除後，外鍵將會被置空。

可使用以下代碼移除此約定：

modelBuilder.Conventions.Remove<OneToManyCascadeDeleteConvention>();

modelBuilder.Conventions.Remove<ManyToManyCascadeDeleteConvention>();

下面的代碼片斷配置爲外鍵不能爲空，並且禁用了級聯刪除。

 

modelBuilder.Entity<Course>()

  .HasRequired(t => t.Department)

  .WithMany(t => t.Courses)

  .HasForeignKey(d => d.DepartmentID)

  .WillCascadeOnDelete(false);

配置組合外鍵

下面的代碼配置了組合外鍵

modelBuilder.Entity<Department>()

  .HasKey(d => new{ d.DepartmentID, d.Name });

 

// Composite foreign key

modelBuilder.Entity<Course>()

    .HasRequired(c => c.Department)

    .WithMany(d => d.Courses)

    .HasForeignKey(d => new { d.DepartmentID, d.DepartmentName });

 

配置不符合命名約定的外鍵屬性

SomeDepartmentID屬性不符合外鍵命名約定，須要使用以下方法將其設置爲外鍵屬性：

modelBuilder.Entity<Course>()

         .HasRequired(c => c.Department)

         .WithMany(d => d.Courses)

         .HasForeignKey(c =>c.SomeDepartmentID);

 

定義DbSet

DbContext 使用DbSet 屬性

Code First 示例中顯示的常見狀況是讓 DbContext 爲模型實體類型使用公共自動 DbSet 屬性。例如：

publicclass BloggingContext: DbContext

{

  public DbSet<Blog>Blogs { get; set;}

  public DbSet<Post>Posts { get; set;}

}

 

在 CodeFirst 模式下使用時，這會將 Unicorn、Princess、LadyInWaiting 和Castle 配置爲實體類型，也將配置可從這些類型訪問的其餘類型。此外，DbContext 還將自動對其中每一個屬性調用 setter 以設置相應 DbSet 的實例。

DbContext 使用IDbSet 屬性

在建立 mock或 fake 等狀況下，更適合使用接口來聲明 set 屬性。在這些狀況下，可以使用 IDbSet 接口替代 DbSet。例如：

publicclass BloggingContext: DbContext

{

  public IDbSet<Blog>Blogs { get; set;}

  public IDbSet<Post>Posts { get; set;}

}

 

此上下文的工做方式與對其 set 屬性使用DbSet 類的上下文徹底相同。

DbContext 使用只讀set 屬性

若是不但願爲DbSet 或 IDbSet 屬性公開公共 setter，能夠改成建立只讀屬性並自建 set 實例。例如：

publicclass BloggingContext: DbContext

{

  public DbSet<Blog>Blogs

  {

    get { return Set<Blog>();}

  }

 

  public DbSet<Post>Posts

  {

    get { return Set<Post>();}

  }

}

請注意，DbContext將緩存從 Set 方法返回的 DbSet 實例，以便每次調用其中每一個屬性時都返回同一實例。

搜索 CodeFirst 實體類型的工做方式與搜索具備公共 getter 和setter 的屬性相同。

DbContext使用注意事項

·         隨着愈來愈多的對象和他們的引用進入內存，DbContext的內存消耗可能會迅速增加，這將會引發性能問題。

·         當再也不使用context對象的時候，必定要釋放它。

·         若是一個異常使得context進入了一個不可恢復的狀態，整個應用可能會終止。

·         長時間使用的context會增長併發衝突的可能。

DbSet使用注意事項

DbSet老是針對數據庫執行查詢，即便要查詢的數據已經在上下文中，下面幾種狀況下會執行數據庫查詢。

·         執行foreach

·         調用ToArray, ToDictionary, ToList.

·         在最外層查詢調用LINQ操做符First，Any等等。

·         DbSet的擴展方法Load，DbEntityEntry.Reload，Database.ExecuteSqlCommand.

當數據庫返回查詢結果的時候，若是結果集中的對象在context中不存在，那麼就會將對象attach到上下文中。若是對象已經存在（根據id來判斷），那麼就會返回在上下文中已經存在的對象，數據庫的值不會覆蓋當前對象database values。在這種狀況下，若是咱們長時間持有DbContext，那麼咱們在每次查詢的時候獲得就頗有可能不是最新版本的對象。

在執行一個查詢的時候，上下文中新添加可是尚未保存的對象不會做爲查詢結果返回，若是想訪問這些對象，須要訪問Local屬性。下面是關於local屬性的備註

1.        Local屬性不僅是包含新添加的對象，它包含全部已經加載到context中的對象。

2.        Local屬性不包含那些已經被Remove的對象（上下文中remove了，可是還在數據庫中）

3.        查詢結果永遠反應數據庫的真實數據，在上下文中被Remove了可是尚未在數據庫刪除的對象，仍然能夠查詢到。DbContext.ChangeTracker屬性提供了DbChangeTracker的實例，該實例的Entries屬性返回一個DbEntityEntry集合，能夠找到全部當前上下文中跟蹤的實體及其狀態信息。

有時候在查詢大量實體並只進行只讀操做的時候，實體跟蹤是沒有任何意義的，禁用實體跟蹤會提升查詢性能，能夠AsNoTracking方法來禁用實體跟蹤，例如：

using(var context = newBloggingContext())

{

  // Query for allblogs without tracking them

  var blogs1 =context.Blogs.AsNoTracking();

 

  // Query for someblogs without tracking them

  var blogs2 =context.Blogs

                      .Where(b =>b.Name.Contains(".NET"))

                      .AsNoTracking()

                      .ToList();

}

 

根據主鍵查找實體

DbSet.Find方法會根據主鍵來查找被上下文跟蹤的實體。若是上下文中不存在此對象，那麼將會對數據庫進行查詢來查找實體，若是沒有找到實體，則返回null。Find方法能夠查詢到剛剛添加到上下文可是尚未被保存到數據庫的實體，這與LINQ查詢不一樣。

使用 Find 方法時必須考慮：

1.        若是對象沒有在緩存中，則 Find 沒有優點，但語法仍比按鍵進行查詢簡單。

2.        若是啓用自動檢測更改，則根據模型的複雜性以及對象緩存中的實體數量，Find 方法的成本可能會增長一個數量級，甚至更多。

此外，請注意Find 僅返回要查找的實體，它不會自動加載未在對象緩存中的關聯實體。若是須要檢索關聯實體，可經過預先加載使用按鍵查詢。

建立和修改關係

對於擁有外鍵屬性的關係，修改關係是很是簡單的，以下：

course.DepartmentID =newCourse.DepartmentID;

下面的代碼經過將外鍵設置爲 null 刪除了關係。請注意，外鍵屬性必須能夠爲 Null。

course.DepartmentID = null;

注意：若是引用處於已添加狀態（在本例中爲 course 對象），在調用 SaveChanges 以前，引用導航屬性將不與新對象的鍵值同步。因爲對象上下文在鍵值保存前不包含已添加對象的永久鍵，所以不發生同步。

經過將一個新對象分配給導航屬性。下面的代碼在 course 和department 之間建立關係。若是對象附加到上下文，course 也會添加到 department.Courses 集合中，course 對象的相應的外鍵屬性設置爲 department 的鍵屬性值。

course.Department =department;

要刪除該關係，請將導航屬性設置爲 null。若是使用的是基於 .NET 4.0 的實體框架，則須要先加載相關端，而後再將其設置爲 Null。例如：

context.Entry(course).Reference(c=> c.Department).Load();

course.Department = null;

從實體框架5.0（它基於 .NET 4.5）開始，沒必要加載相關端就能夠將關係設置爲 Null。也可使用如下方法將當前值設置爲 Null。

context.Entry(course).Reference(c=> c.Department).CurrentValue = null;

經過在實體集合中刪除或添加對象。例如，能夠將 Course 類型的對象添加到 department.Courses 集合中。此操做將在特定 course 和特定 department 之間建立關係。若是對象附加到上下文，course 對象的 department 引用和外鍵屬性將設置爲相應的 department。

department.Courses.Add(newCourse);

此處，若是course的departmentid不能爲空，則可能會出現錯誤，對department.Courses集合不能有刪除course的操做，不然會出現錯誤。由於若是從集合中移除了course，在SaveChanges過程當中把該過程識別爲更新關係，而那些被刪除的course的departmentid又不能爲空，因此save不會成功。

經過使用 ChangeRelationshipState方法更改兩個實體對象間指定關係的狀態。此方法是處理 N 層應用程序和獨立關聯 時最經常使用的方法（不能用於外鍵關聯）。此外，要使用此方法，必須下拉到 ObjectContext，以下例所示。

在下面的示例中，Instructor和 Course 之間存在多對多關係。調用 ChangeRelationshipState 方法並傳遞 EntityState.Added 參數，使 SchoolContext 知道在這兩個對象間添加了關係。

       ((IObjectContextAdapter)context).ObjectContext.ObjectStateManager.

                 ChangeRelationshipState(course, instructor, c => c.Instructor,EntityState.Added);  

請注意，若是是更新（而不只是添加）關係，添加新關係後必須刪除舊關係：

      ((IObjectContextAdapter)context).ObjectContext. ObjectStateManager.

                 ChangeRelationshipState(course, oldInstructor, c => c.Instructor,EntityState.Deleted);   

同步FK 和導航屬性之間的更改

使用上述方法中的一種更改附加到上下文的對象的關係時，實體框架須要保持外鍵、引用和集合同步。實體框架使用代理自動管理 POCO 實體的這種同步（也稱爲關係修復）。

若是不經過代理使用POCO 實體，則必須確保調用 DetectChanges 方法同步上下文中的相關對象。請注意，下面的 API 會自動觸發 DetectChanges 調用。

·         DbSet.Add

·         DbSet.Find

·         DbSet.Remove

·         DbSet.Local

·         DbContext.SaveChanges

·         DbSet.Attach

·         DbContext.GetValidationErrors

·         DbContext.Entry

·         DbChangeTracker.Entries

·         對 DbSet 執行 LINQ 查詢

若是context中有不少實體，並且你正在屢次調用上述方法，那麼就會形成很大的性能影響。可使用下面的代碼來的代碼禁用自動檢測：

using(var context = newBloggingContext())

{

  try

  {

   context.Configuration.AutoDetectChangesEnabled = false;

 

    // Make manycalls in a loop

    foreach (var blog inaLotOfBlogs)

    {

      context.Blogs.Add(blog);

    }

  }

  finally

  {

   context.Configuration.AutoDetectChangesEnabled = true;

  }

}

除了以上方法，還能夠調用context.ChangeTracker.DetectChanges方法來顯式檢測變化。須要當心使用這些高級方法，不然很容易在你的程序裏引入微妙的bug。

加載相關對象

預加載（EagerlyLoading）

預加載表示在查詢某類實體時一塊兒加載相關實體，這是使用Include方法完成的，以下：

using(var context = newBloggingContext())

{

  // Load all blogsand related posts

  var blogs1 =context.Blogs

.Include(b=> b.Posts)

.ToList();

 

  // Load one blogsand its related posts

  var blog1 =context.Blogs

.Where(b=> b.Name == "ADO.NET Blog")

.Include(b=> b.Posts)

.FirstOrDefault();

 

  // Load all blogsand related posts

  // using a stringto specify the relationship

  var blogs2 =context.Blogs

                        .Include("Posts")

                        .ToList();

 

  // Load one blogand its related posts

  // using a stringto specify the relationship

  var blog2 =context.Blogs

                      .Where(b => b.Name == "ADO.NET Blog")

                      .Include("Posts")

                      .FirstOrDefault();

}

注意：Include方法是一個擴展方法，在System.Data.Entity命名空間下，確保引用了此命名空間。

多級預加載

下面的代碼顯示瞭如何加載多級實體。

using(var context = newBloggingContext())

{

  // Load all blogs,all related posts, and all related comments

  var blogs1 =context.Blogs

                     .Include(b =>b.Posts.Select(p => p.Comments))

                     .ToList();

 

  // Load all userstheir related profiles, and related avatar

  var users1 =context.Users

                      .Include(u =>u.Profile.Avatar)

                      .ToList();

 

  // Load all blogs,all related posts, and all related comments

  // using a stringto specify the relationships

  var blogs2 =context.Blogs

                     .Include("Posts.Comments")

                     .ToList();

 

  // Load all userstheir related profiles, and related avatar

  // using a stringto specify the relationships

  var users2 =context.Users

                      .Include("Profile.Avatar")

                      .ToList();

}

當前不支持在關聯實體上進行查詢，Include方法老是加載全部關聯實體。

惰性加載

惰性加載指的是當第一訪問導航屬性的時候自動從數據庫加載相關實體。這種特性是由代理類實現的，代理類派生自實體類，並重寫了導航屬性。因此咱們的實體類的導航屬性就必須標記爲virtual，以下：

publicclass Blog

{

  public int ID { get; set; }

  public string Title { get; set; }

  public virtual ICollection<Post>Posts { get; set;}

}

能夠對指定實體關閉惰性加載，以下：

publicclass Blog

{

  public int ID { get; set; }

  public string Title { get; set; }

  public ICollection<Post>Posts { get; set;}

}

也能夠對全部實體關閉惰性加載，以下：

publicclass BloggingContext: DbContext

{

  publicBloggingContext()

  {

    this.Configuration.LazyLoadingEnabled= false;

  }

}

顯式加載

即便關閉了惰性加載，咱們仍然能夠經過顯式調用來延遲加載相關實體，這是經過調用DbEntityEntry上的相關方法作到的，以下：

using(var context = newBloggingContext())

{

  var post =context.Posts.Find(2);

 

  // Load the blogrelated to a given post

  context.Entry(post).Reference(p => p.Blog).Load();

 

  // Load the blogrelated to a given post using a string

  context.Entry(post).Reference("Blog").Load();

 

  var blog =context.Blogs.Find(1);

 

  // Load the postsrelated to a given blog

  context.Entry(blog).Collection(p =>p.Posts).Load();

 

  // Load the postsrelated to a given blog

  // using a stringto specify the relationship

  context.Entry(blog).Collection("Posts").Load();

}

 

注意：在外鍵關聯中，加載依賴對象的相關端時，將根據內存中當前的相關外鍵值加載相關對象：

// Get thecourse where currently DepartmentID = 1.

Course course2 =context.Courses.First(c=>c.DepartmentID == 2);

 // UseDepartmentID foreign key property

// to change theassociation.

course2.DepartmentID = 3;

 // Load therelated Department where DepartmentID = 3

context.Entry(course).Reference(c=> c.Department).Load();

在獨立關聯中，基於當前數據庫中的外鍵值查詢依賴對象的相關端。不過，若是修改了關係，而且依賴對象的引用屬性指向對象上下文中加載的不一樣主對象，實體框架將嘗試建立關係，就像它在客戶端定義的那樣。

Query方法提供了在加載相關實體的時候應用過濾條件的功能，引用導航屬和集合導航屬性都支持Query方法，可是大部分狀況下都會針對集合導航屬性使用Query方法，達到只加載部分相關實體的功能，以下：

using(var context = newBloggingContext())

{

  var blog =context.Blogs.Find(1);

 

  // Load the postswith the 'entity-framework' tag related to a given blog

  context.Entry(blog)

      .Collection(b => b.Posts)

      .Query()

      .Where(p => p.Title.Contains("entity-framework"))

      .Load();

 

  // Load the postswith the 'entity-framework' tag related to a given blog

  // using a stringto specify the relationship

  context.Entry(blog)

      .Collection("Posts")

      .Query()

      .Cast<Post>()

      .Where(p => p.Title.Contains("entity-framework"))

      .Load();

}

注意，使用顯式加載的時候，最好關閉惰性加載，避免引發混亂。Load方法是一個擴展方法，記得引用命名空間System.Data.Entity.DbExtensions

使用Query查詢相關實體個數，而不用加載相關實體，以下：

using(var context = newBloggingContext())

{

  var blog =context.Blogs.Find(1);

 

  // Count how manyposts the blog has

  var postCount= context.Entry(blog)

                        .Collection(b =>b.Posts)

                        .Query()

                        .Count();

}

 

使用代理

爲 POCO 實體類型建立實例時，實體框架經常爲充當實體代理的動態生成的派生類型建立實例。此代理重寫實體的某些虛擬屬性，這樣可在訪問屬性時插入掛鉤，從而自動執行操做。例如，此機制用於支持關係的延遲加載。

禁止建立代理

有時須要禁止實體框架建立代理實例。例如，人們一般認爲序列化非代理實例要比序列化代理實例容易得多。可經過清除 ProxyCreationEnabled 標記來關閉代理建立功能。上下文的構造函數即是可執行此操做的一個位置。例如：

publicclass BloggingContext: DbContext

{

  publicBloggingContext()

  {

    this.Configuration.ProxyCreationEnabled= false;

  }

 

  public DbSet<Blog>Blogs { get; set;}

  public DbSet<Post>Posts { get; set;}

}

請注意，在無需代理執行任何操做的狀況下，EF 不會爲類型建立代理。這意味着，也能夠經過使用封裝和/或沒有虛擬屬性的類型，避免生成代理。

添加新實體

使用DbSet.Add方法添加實體

using(var context = newBloggingContext())

{

  var blog = new Blog { Name = "ADO.NET Blog" };

  context.Blogs.Add(blog);

  context.SaveChanges();

}

 

修改Entry的State來添加實體

using(var context = newBloggingContext())

{

  var blog = new Blog { Name = "ADO.NET Blog" };

  context.Entry(blog).State =EntityState.Added;

  context.SaveChanges();

}

 

設置導航屬性來添加實體

using(var context = newBloggingContext())

{

  // Add a new Userby setting a reference from a tracked Blog

  var blog =context.Blogs.Find(1);

  blog.Owner = newUser { UserName = "johndoe1987" };

 

  // Add a new Postby adding to the collection of a tracked Blog

  var blog =context.Blogs.Find(2);

  blog.Posts.Add(newPost { Name = "Howto Add Entities" });

 

  context.SaveChanges();

}

全部被添加到上下文中的實體的引用實體，若是沒有被跟蹤，就會被看成新實體添加到上下文中，並在調用SaveChanges方法後被保存到數據庫。

附加實體到上下文

若是實體在數據庫中存在，可是沒有被上下文跟蹤，但是使用DbSet.Attach方法將其附加到上下文，附加以後，實體處於Unchanged狀態。處於Unchanged狀態的實體不會參與SaveChanges的邏輯。

varexistingBlog = new Blog{ BlogId = 1, Name = "ADO.NET Blog"};

 

using(var context = newBloggingContext())

{

  context.Blogs.Attach(existingBlog);

 

  // Do some morework...

 

  context.SaveChanges();

}

設置DbEntityEntry對象的State屬性，也能夠附加對象到上下文中，以下：

varexistingBlog = new Blog{ BlogId = 1, Name = "ADO.NET Blog"};

 

using(var context = newBloggingContext())

{

  context.Entry(existingBlog).State =EntityState.Unchanged;

 

  // Do some morework...

 

  context.SaveChanges();

}

使用上述兩種方法附加到上下文的實體若是還引用其餘實體，那麼這些實體也會被附加到上下文中，狀態爲Unchanged

使用以下方法附加一個存在於數據庫，可是尚未附加到上下文的已修改實體：

varexistingBlog = new Blog{ BlogId = 1, Name = "ADO.NET Blog"};

 

using(var context = newBloggingContext())

{

  context.Entry(existingBlog).State =EntityState.Modified;

 

  // Do some morework...

 

  context.SaveChanges();

}

若是把一個實體的狀態置爲Modified，那麼該實體的全部屬性都將被標記爲已更改狀態，當SaveChanges被調用時，全部的屬性值都將被保存到數據庫。若是不想保存全部值，能夠單獨爲每一個想要修改的屬性設置IsModified屬性，以下：

using(var context = newBloggingContext())

{

    var blog =context.Blogs.Find(1);

 

    context.Entry(blog).Property(u =>u.Name).IsModified = true;

 

    // Use a stringfor the property name

    context.Entry(blog).Property("Name").IsModified = true;

}

 

若是該實體還引用其餘未被跟蹤實體，那麼這些實體將會做爲Unchanged狀態的實體附加到上下文。若是想修改這些實體，只能單獨把每一個引用實體設置爲修改狀態。

樂觀併發模式

在嘗試保存使用外鍵關聯的實體期間，若是檢測到樂觀併發異常，SaveChanges 將引起 DbUpdateConcurrencyException。DbUpdateConcurrencyException的 Entries 方法爲沒法更新的實體返回 DbEntityEntry 實例。

使用DbContext執行原始SQL

使用SqlQuery方法執行SQL查詢

using(var context = newBloggingContext())

{

  var blogs =context.Blogs.SqlQuery("SELECT * FROMdbo.Blogs").ToList();

}

執行存儲過程查詢

using(var context = newBloggingContext())

{

  var blogs =context.Blogs.SqlQuery("dbo.GetBlogs").ToList();

}

 

爲存儲過程傳遞參數

using(var context = newBloggingContext())

{

  var blogId =1;

 

  var blogs =context.Blogs.SqlQuery("dbo.GetBlogById@p0", blogId).Single();

}

查詢非實體類型

using(var context = newBloggingContext())

{

  var blogNames= context.Database.SqlQuery<string>(

                     "SELECTName FROM dbo.Blogs").ToList();

}

返回是的對象將不會被跟蹤，即便返回類型是實體類型。

執行SQL命令

using(var context = newBloggingContext())

{

  context.Database.SqlCommand(

      "UPDATEdbo.Blogs SET Name = 'Another Name' WHERE BlogId = 1");

}