實體框架核心（EF Core）是Entity Framework的一個輕量級，可擴展和跨平台版本。 10月25日，Entity Framework Core 1.1 Preview 1發布了。
如果您使用由EF團隊（SQL Server，SQLite和InMemory）提供的數據庫提供程序之一，則只需升級提供程序包。
PM> Update-Package Microsoft.EntityFrameworkCore.SqlServer –Pre
如果您使用的是第三方數據庫提供程序，請檢查它們是否已發布依賴於1.1.0-preview1-final的更新。 如果他們有，那麼只是升級到新版本。 如果沒有，那麼你應該只能升級它們依賴的EF Core關系組件。 1.1中的大部分新功能不需要更改數據庫提供程序。 EF開發組做了一些測試，以確保依賴於1.0的數據庫提供程序繼續使用1.1預覽1，但這個測試還不詳盡。
PM> Update-Package Microsoft.EntityFrameworkCore.Relational –Pre
如果你使用的工具包，那麼一定要升級。 請注意，工具版本化為1.0.0-preview3-final，因為工具尚未達到其初始穩定版本（在.NET Core，ASP.NET Core和EF Core上的工具都是如此）。
PM> Update-Package Microsoft.EntityFrameworkCore.Tools –Pre
如果您使用的是ASP.NET Core，那麼您需要更新project.json的tools部分以使用新的Microsoft.EntityFrameworkCore.Tools.DotNet包。 隨著.NET CLI工具的設計的進行，我們必須將dotnet ef工具分離到這個單獨的包中。
"tools": {
"Microsoft.EntityFrameworkCore.Tools.DotNet": "1.0.0-preview3-final"
},1.1版本專注於解決阻止人們采用EF Core的問題。 這包括修復錯誤並添加一些尚未在EF Core中實現的關鍵功能。 雖然EF開發組在這方面取得了一些良好的進展，但是，EF Core仍然不會是每個人的正確選擇。 有關實現的更多詳細信息，請參閱下面的EF Core和EF6.x比較。
有兩個版本的Entity Framework，Entity Framework Core和Entity Framework 6.x.
Entity Framework 6.x（EF6.x）是一種經過試驗和測試的數據訪問技術，具有多年的功能和穩定性。 它首次在2008年發布，作為.NET Framework 3.5 SP1和Visual Studio 2008 SP1的一部分。 從EF4.1版本開始，它作為EntityFramework NuGet包發運 - 目前是NuGet.org上最受歡迎的包。
EF6.x繼續是一個受支持的產品，並將繼續進行錯誤修復和小的改進。
實體框架核心（EF Core）是Entity Framework的一個輕量級，可擴展和跨平台版本。 與EF6.x相比，EF Core引入了許多改進和新功能。 同時，EF Core 是一個新的代碼基礎
EF Core保留了來自EF6.x的開發者體驗，大多數頂級API也保持不變，因此EF Core對使用EF6.x的用戶會感到非常熟悉。 同時，EF Core構建了一套全新的核心組件。 這意味著EF Core不會自動繼承EF6.x的所有功能。 其中一些功能將在未來版本中顯示（例如延遲加載和連接彈性），其他較不常用的功能將不會在EF Core中實現。
新的，可擴展的和輕量級核心還允許我們在EF核心中添加一些在EF6.x中不能實現的特性（例如在LINQ查詢中的備用密鑰和混合客戶端/數據庫評估）。
在1.1版本中，EF研發團隊在改進EF Core LINQ提供程序方面取得了良好的進展。 這使得更多的查詢能夠成功執行，在數據庫（而不是內存）中評估更多的邏輯。
DbSet.Find（...）是一個存在於EF6.x中的API，並且是EF Core的更常見的請求之一。 它允許您根據主鍵值輕松查詢實體。 如果實體已經加載到上下文中，則返回它而不查詢數據庫。
using (var db = new BloggingContext())
{
var blog = db.Blogs.Find(1);
}API中的新的HasField（...）方法允許您為屬性配置備用字段。 這是最常見的做法是當一個屬性沒有setter。
public class BloggingContext : DbContext
{
...
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<Blog>()
.Property(b => b.Url)
.HasField("_theUrl");
}
}默認情況下，EF將在查詢期間構造實體的實例時使用該字段，或者當它無法使用該屬性時（即，它需要設置值，但沒有屬性設置器）。 您可以通過新的UsePropertyAccessMode（...）API更改。
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<Blog>()
.Property(b => b.Url)
.HasField("_theUrl")
.UsePropertyAccessMode(PropertyAccessMode.Field);
}您還可以在模型中創建在實體類中沒有相應屬性的屬性，但使用字段將數據存儲在實體中。 這與“陰影屬性”(下面介紹，距離此處12cm)不同，數據存儲在更改跟蹤器中。 如果實體類使用方法來獲取/設置值，則通常使用此方法。
您可以在屬性（...）API中給EF字段的名稱。 如果沒有具有給定名稱的屬性，則EF將尋找一個字段。
public class BloggingContext : DbContext
{
...
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<Blog>()
.Property("_theUrl");
}
}您還可以選擇為該屬性指定名稱，而不是字段名稱。 然後在創建模型時使用此名稱，最明顯的是它將用於映射到數據庫中的列名稱。
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<Blog>()
.Property<string>("Url")
.HasField("_theUrl");
}您可以使用EF.Property（...）方法在LINQ查詢中引用這些屬性。
var blogs = db.Blogs
.OrderBy(b => EF.Property<string>(b, "Url"))
.ToList();陰影屬性是實體類中不存在的屬性。 這些屬性的值和狀態完全保留在更改跟蹤器中
可以通過ChangeTracker API獲取和更改陰影屬性值。
context.Entry(myBlog).Property("LastUpdated").CurrentValue = DateTime.Now;
陰影屬性可以通過EF.Property靜態方法在LINQ查詢中引用。
var blogs = context.Blogs .OrderBy(b => EF.Property<DateTime>(b, "LastUpdated"));
按照慣例，僅當發現關系時才創建陰影屬性，但在從屬實體類中找不到外鍵屬性。 在這種情況下，將引入影子外鍵屬性。 shadow外鍵屬性將命名為<navigation property name><principal key property name>（在依賴實體上的導航，它指向主體實體，用於命名）。 如果主鍵屬性名稱包含導航屬性的名稱，則名稱將只是<principal key property name>。 如果從屬實體上沒有導航屬性，則在其位置使用主類型名稱。
例如，以下代碼清單將導致向Post實體引入BlogId shadow屬性。
class MyContext : DbContext
{
public DbSet<Blog> Blogs { get; set; }
public DbSet<Post> Posts { get; set; }
}
public class Blog
{
public int BlogId { get; set; }
public string Url { get; set; }
public List<Post> Posts { get; set; }
}
public class Post
{
public int PostId { get; set; }
public string Title { get; set; }
public string Content { get; set; }
public Blog Blog { get; set; }
}
無法使用數據注釋創建陰影屬性。
您可以使用Fluent API配置陰影屬性。 一旦你調用了Property的字符串重載，你就可以鏈接任何對其他屬性的配置調用。
如果提供給Property方法的名稱與現有屬性（陰影屬性或實體類上定義的屬性）的名稱匹配，則代碼將配置現有屬性，而不是引入新的shadow屬性。
class MyContext : DbContext
{
public DbSet<Blog> Blogs { get; set; }
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<Blog>()
.Property<DateTime>("LastUpdated");
}
}
public class Blog
{
public int BlogId { get; set; }
public string Url { get; set; }
}
陰影屬性介紹完畢！
顯式加載允許您加載由上下文跟蹤的實體的導航屬性的內容。
using (var db = new BloggingContext())
{
var blog = db.Blogs.Find(1);
db.Entry(blog).Collection(b => b.Posts).Load();
db.Entry(blog).Reference(b => b.Author).Load();
}EF研發團隊添加了EF6.x中提供的其余EntityEntry API。 這包括Reload（），GetModifiedProperties（），GetDatabaseValues（）等。這些API最常用的是通過調用DbContext.Entry（對象實體）方法。
連接彈性自動重試失敗的數據庫命令。 此版本包括專為SQL Server（包括SQL Azure）定制的執行策略。 此執行策略包含在我們的SQL Server提供程序中。 它知道可以重試的異常類型，並且具有明顯的默認值，用於最大重試次數，重試之間的延遲等。
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
optionsBuilder.UseSqlServer(
"<connection string>",
options => options.EnableRetryOnFailure());
}其他數據庫提供者可以選擇添加為其數據庫定制的重試策略。 還有一種機制來注冊自己的自定義執行策略。
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
optionsBuilder.UseMyProvider(
"<connection string>",
options => options.ExecutionStrategy(...));
}
內存優化表是SQL Server的一項功能。 您現在可以指定實體映射到的表是內存優化的。 當使用EF Core基於您的模型（使用遷移或Database.EnsureCreated）創建和維護數據庫時，將為這些實體創建一個內存優化表。
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<Blog>()
.ForSqlServerIsMemoryOptimized();
}在EF Core 1.0中，可以替換EF使用的內部服務，但這是復雜的，需要您控制EF使用的依賴注入容器。 在1.1中，我們使用了一個ReplaceService（...）方法，可以在配置上下文時使用它。
public class BloggingContext : DbContext
{
...
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
...
optionsBuilder.ReplaceService<SqlServerTypeMapper, MyCustomSqlServerTypeMapper>();
}
}穩定的1.1版本將於今年晚些時候推出。 EF研發團隊不計劃在preview1和穩定版本之間添加任何新功能。 將只是努力修復報告的錯誤。
EF研發團隊現在將注意力轉移到EF Core 1.2和EF6.2版本。 將在不久的將來分享這些版本的詳細信息。
貼一張Rowan Miller的帥照。Microsoft員工，EF研發團隊成員，他的個人Blog：https://romiller.com/，有興趣的朋友可以去看看。
最後，希望本文對你有所幫助。
轉載請注明出處，轉載請注明出處，轉載請注明出處，重要的事情說三遍：http://www.cnblogs.com/smallprogram/
