Entity Framework Core 2.0 特性介绍和使用指南

前言

这是.Net Core 2.0生态生态介绍的最后一篇,EF一直是我喜欢的一个ORM框架,随着版本升级EF也发展到EF6.x,Entity Framework Core是一个支持跨平台的全新版本,可以用三个词来概况EF Core的特点:轻量级、可扩展、跨平台。跨平台的特性是EF6.x无法替代的优势,也许会成为你在项目中技术选型的原因之一。

获取和使用

在命令行工具安装NuGet包,比如:安装SQL Server EF Core提供程序,并指定版本为2.0.0

$ dotnet add package Microsoft.EntityFrameworkCore.SqlServer -V 2.0.0

在VS2017中使用包管理器控制台安装

PM> Install-Package Microsoft.EntityFrameworkCore.SqlServer -Version 2.0.0

在ASP.NET Core 2.0默认项目包含支持EF Core 2.0的SQL Server, SQLite, 和 in-memory数据库提供程序,创建项目无需额外添加。

查看在不同平台上使用EF Core指南,查看更多安装和升级细节,进入帮助文档。

新特性

以下是最显著的新特性:

  • 使用.NET Standard 2.0目标框架:这使得EF Core 2.0可支持多种.NET平台实现和应用程序类型,查看平台支持列表。

  • LINQ解析改进:EF Core 2.0中的查询更加高效,适应多种场景。举个例子,增加了翻译成SQL语句模式的数量限制,避免了在以前版本中因为客户端计算导致多重查询的问题。(优化了客户端计算性能)

  • Like查询支持:LINQ查询可以使用EF.Functions.Like(),最终解析为SQL中的like语句,在必要的时候会进行内存计算,举个例子,下面的查询:

    var customers =
    from c in context.Customers
    where EF.Functions.Like(c.Name, "a%");
    select c;

解析成SQL语句:

  SELECT [c].[Id], [c].[Name]  FROM [Customers] AS [c]  WHERE [c].[Name] LIKE N'a%';

和SQL中like语句一样使用通配符。

  • 实体包含关系和表拆分:可以通过属性关联建立实体之间的包含关系,这个特性和EF6中的复合类型类似,只需要定义一个导航属性。实体包含关系定义与表拆分结合使用,可以将两个实体自动映射为单张表,参看下面的示例:

    public class Customer{  
     public int Id { get; set; }  
     
  •  public string Name {get; set;}   
     
  •  public PhysicalAddress Address { get; set; }
    }public class PhysicalAddress{   
     
  •  public string StreetAddress { get; set; }    public Location Location { get; set; }
    }
    
    ...
    
    modelBuilder.Entity<Customer>()
        .OwnsOne(c => c.Address);
  • 全局查询过滤器:在DbContext中为实体定义查询过滤器,下面代码在OnModelCreating方法中定义:

    modelBuilder.Entity<Post>() .HasQueryFilter(p => !p.IsDeleted);

下面的查询只会返回未被标记为删除的结果:

  var blog = context.Blogs
  .Include(b => b.Posts)
  .FirstOrDefault(b => b.Id == id);

这个特性在特殊的业务场景下将有大用处,比如多租户中数据过滤实现。

  • DbContext Pooling(池):这项特性能够显著提升Asp.net Core应用程序的性能,通过在服务注册DbContext类型时启用,使用预先创建的实例池,避免为每个请求创建新实例:

    services.AddDbContextPool (
    options => options.UseSqlServer(connectionString));

    这是一个最佳实践,推荐使用!

  • SQL方法支持字符串插值:下面的SQL语句使用了C#中字符串插值语法,简化参数化查询:

    var city = "Redmond";
  • using (var context = CreateContext())
  • {
        context.Customers.FromSql($@"        SELECT *        FROM Customers        WHERE City = {city}");
    }

以上代码转换为SQL语句会创建一个名为@p0的参数,值为Redmond,生成如下SQL语句:

    SELECT *    FROM Customers    WHERE City = @p0
  • 更多特性:如:显式编译查询、自包含实体配置、数据库标准函数映射。还修复了许多Bug。详细内容参考:新功能


项目升级和核心API变化

  1. 将项目.NET平台设置为支持.NET Standard 2.0的平台

  2. 使用支持2.0的数据库提供程序

  3. 更新EF Core引用包(包括运行时和工具)到2.0

  4. 必要的时候对代码进行修改,具体参看核心变化

在2.0版本中,部分API和操作有较大该井,有部分改进需要修改现有程序代码,对于大多数应用程序来说,影响不大,大多数情况下,只需要重新编译和最少的修改来替换过时的API。

获取应用程序服务新方式

注:EF Core在设计时的操作比如生成数据迁移代码,更新数据库,需要访问应用程序服务。设计时工具和应用程序存在调用关系。

推荐将ASP.NET Core Web应用程序更新到2.0,在ASP.NET Core 2.0在启动类之外初始化配置。在之前的版本EF Core尝试执行Startup.ConfigureServices,直接访问应用程序的服务提供者,使用EF Core的应用程序通常从配置文件中访问连接字符串,所以单靠Startup已经不能满足获取连接字符串的需要。

更新ASP.NET Core 1.x到2.0,当使用了EF Core工具,会收到如下错误提示:

No parameterless constructor was found on 'ApplicationContext'. Either add a parameterless constructor to 'ApplicationContext' or add an implementation of 'IDesignTimeDbContextFactory ' in the same assembly as 'ApplicationContext'

在ASP.NET Core 2.0默认模板中新增设计时支持,静态方法Program.BuildWebHost允许EF Core在设计时访问应用程序服务提供者,如果升级ASP.NET Core 1.x应用程序,同时升级Program

using Microsoft.AspNetCore;
using Microsoft.AspNetCore.Hosting;

namespace AspNetCoreDotNetCore2._0App{  
 public class Program    {        public static void Main(string[] args)        {            BuildWebHost(args).Run();        }        public static IWebHost BuildWebHost(string[] args) =>            WebHost.CreateDefaultBuilder(args)                .UseStartup<Startup>()                .Build();    } }

注:如果没有ASP.NET Core 2.0应用程序没有更改Program启动方式,依然可以使用实现IDesignTimeDbContextFactory<ApplicationContext>接口方式提供EF Core 2.0设计时支持,不推荐这么做。

IDbContextFactory改名

为了支持不同的应用模式,在设计时提供对DbContext更多自定义控制,在以前的版本提供接口IDbContextFactory<TContext>,EF Core工具在设计时,会发现应用程序中该接口的实现并使用它来创建DbContext对象。

这个接口因为具有通用性的名称,容易误导开发者使用来处理需要重新创建DbContext的开发场景,当在设计时EF Core工具使用它时因为没有考虑到设计时的特殊环境可以导致Update-Databasedotnet ef database update命令执行失败。

基于以上的原因,为了更精准的表达该接口的作用,我们将其改名为IDesignTimeDbContextFactory<TContext>,在2.0中IDbContextFactory<TContext>仍然存在,但是已经标记为过时了。

DbContextFactoryOptions移除

因为ASP.NET 2.0的升级,我们发现在接口IDesignTimeDbContextFactory<TContext>不在需要DbContextFactoryOptions
下面是你应该使用的替代方案。

  • DbContextFactoryOptions.ApplicationBasePath 使用AppContext.BaseDirectory代替

  • DbContextFactoryOptions.ContentRootPath 使用Directory.GetCurrentDirectory()代替

  • DbContextFactoryOptions.EnvironmentName 使用Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT")代替

EF Core 2.0需要2.0数据库提供程序

对于EF Core 2.0,我们已经对数据库提供程序的工作进行了许多简化和改进。1.0.x和1.1.x提供程序已经不能在EF Core 2.0下工作。

由EF团队开发的SQL Server和SQLite数据库提供程序,2.0版本将在2.0版本中提供。其他数据库提供程序也已经升级到2.0版本:

  • SQL Compact

  • PostgreSQL

  • MySQL

日志记录和诊断事件更改

注意:这些更改不会影响大多数的应用程序代码。

发送给ILogger的消息的事件ID在2.0中发生了变化。现在在EF Core中事件ID是全局唯一的。这些消息现在也遵循了结构化日志的标准模式,例如,MVC。

Logger类别也发生了变化,类别可通过DbLoggerCategory访问。

DiagnosticSource事件现在使用与对应ILogger消息相同的时间ID名称,事件ID、有效负载类型和类别进行了统一。

ID从Microsoft.EntityFrameworkCore.Infraestructure命名空间移到Microsoft.EntityFrameworkCore.Diagnostics

EF Core元数据关系API变化

EF Core 2.0为不同的提供程序创建一个不同的IModel,这通常对应用程序是透明的,从而简化了底层元数据API,使得任何对公共关系的元数据都可以通过调用来实现,对比如下代码,在1.1.x中代码:

var tableName = context.Model.FindEntityType(typeof(User)).SqlServer().TableName;

现在可以这么写

var tableName = context.Model.FindEntityType(typeof(User)).Relational().TableName;

更具通用性。

在比如使用方法ForSqlServerToTable,现在可以使用更加通用的代码来实现

modelBuilder.Entity<User>().ToTable(Database.IsSqlServer() ? "SqlServerName" : "OtherName");

请注意,此更改仅适用于为所有关系提供程序定义的API/元数据。当只针对单个提供者时,API和元数据仍然是相同的。举个例子,聚集索引是SQL Server特有的,所以ForSqlServerIsClustered.SqlServer().IsClustered()必须使用。

不要控制EF服务提供程序

EF Core使用内置IServiceProvider在框架内部实现,应用程序应该允许EF Core创建和管理这个提供程序。强烈建议删除所有UseInternalServiceProvider的调用,AddEntityFrameworkAddEntityFrameworkSqlServer不需要通过应用程序代码调用,建议移除。AddDbContext的使用方式和以前一样。

内存数据库必须命名

全局匿名内存数据库已经被删除,而所有内存数据库都必须被命名。

optionsBuilder.UseInMemoryDatabase("MyDatabase");

名称相同就算调用多次,仍然使用同一个数据库,允许由多个上下文实例共享。

Read-only API 变化

IsReadOnlyBeforeSaveIsReadOnlyAferSave, 和 IsStoreGeneratedAlways 已经过时,由 BeforeSaveBehavior 和 AfterSaveBehavior代替。这些行为应用到任何属性(不仅是存储生成的属性)并检测属性值如何被使用,比如插入数据库行(BeforeSaveBehavior)或更新现有数据库行(AfterSaveBehavior)。

属性通过ValueGenerated.OnAddOrUpdate进行标记,例如:计算列。默认情况下,将忽略当前设置在该属性上的任何值。这意味着无论是否在跟踪实体上设置或修改了任何值,都将始终获得一个存储生成的值。这可以通过设置不同的Before\AfterSaveBehavior来改变。

新的ClientSetNull删除行为

在以前的版本中DeleteBehavior.Restrict通过上下文对实体有一个跟踪行为,这些实体与SetNull语义更加封闭。在EF Core 2.0中一个新的行为ClientSetNull作为可选关系的默认值。此行为为跟踪实体设置了SetNull语义,并限制使用EF Core创建的数据库的行为。根据我们的经验这对跟踪实体和数据库是非常有用的。

设计时提供程序更改

Microsoft.EntityFrameworkCore.Relational.Design引用包移除,功能被整合进Microsoft.EntityFrameworkCore.Relational 和 Microsoft.EntityFrameworkCore.Design引用包。

不同数据设计时引用包,比如Microsoft.EntityFrameworkCore.Sqlite.DesignMicrosoft.EntityFrameworkCore.SqlServer.Design,整合进其主提供程序中。

在EF Core 2.0中启用Scaffold-DbContext 或 dotnet ef dbcontext scaffold 现在只需要引用单一的包

<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer"
    Version="2.0.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools"
    Version="2.0.0"
    PrivateAssets="All" />
<DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet"
    Version="2.0.0" />


下一步计划

已经在进行下一个版本的开发,查看开发计划,另外也在完成EF 6.2。


遗憾的地方

  • 不支持GroupBy、延迟加载——这两个特性都在2.1计划中

相关文章: 

原文地址:http://www.cnblogs.com/YGYH/p/7416275.html


.NET社区新闻,深度好文,微信中搜索dotNET跨平台或扫描二维码关注

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值