0. 前言
到目前为止,我们看了一下如何声明 EF Core 的初步使用,也整体的看了下 EF Core 的映射关系配置以及导航属性的配置。
这一篇,我带大家分享一下,我在工作中需要的 EF Core 的用法。
1. 初始化
在实际开发中,一般都是先设计好数据表再进行开发,所以很少用到 EF Core 的数据迁移功能。所以 EF Core 的初始化,一般也指的是 EF Core 上下文初始化。
1.1 连接字符串
我们通过前面的文章知道,EF Core 在上下文初始化的时候,都需要一个链接字符串。如果在不考虑后续变更或者上下文的复用性,可以直接在自定义 Context 里重写 OnConfiguring 方法中定义。
如果需要后续变更,那么就需要在创建自定义 EF Core 上下文类的时候,为之添加一个连接字符串的属性或者字段,以方便初始化的时候指定。实例:
public class DefaultContext : DbContext
{private string Connection { get; set;} = "Data Source=./blogging1.db";
public DefaultContext(string connection)
{Connection = connection;}
protected override void OnConfiguring(DbContextOptionsBuilder options)
=> options.UseSqlite(Connection);
}
这样一来,我们在后续使用的时候,就可以指定连接字符串了。当然了,如果有小伙伴有更好的方法也可以分享出来呀。
1.2 配置文件的加载或者实体对象的托管
如果我们不使用配置文件的话,就必须在 EF Core 的上下文类里添加一个类型是 DbSet<T> 的属性。继续延续上面的实例:
public class SingleModel
{public int Id { get; set;}
public int TargetId {get; set;}
public SingleTargetModel SingleTarget {get; set;}
}
public class SingleTargetModel
{public int Id { get; set;}
public SingleModel Single {get; set;}
}
public class DefaultContext : DbContext
{
// 其余代码参见 1.1 DefaultContext
public DbSet<SingleModel> Singles {get; set;}
public DbSet<SingleTargetModel> Targets {get; set;}
}
以上也就是这一小节标题中的实体对象的托管。我没找到 EF Core 官方文档中对于这种方式的称呼,所以我就悄悄的抢注了一下为托管。
如果我们使用 Config 类(也就是《C# 数据操作系列 – 7. EF Core 导航属性配置》中介绍的配置类)的话,需要在 EF Core 中应用配置,具体是:
protected override void OnModelCreating(ModelBuilder modelBuilder)
{modelBuilder.ApplyConfiguration(new SingleModelConfig());
modelBuilder.ApplyConfiguration(new SingleTargeModelConfig());
}
在使用的时候,可以直接:
var context = new DefaultContext("Data Source=demo.db");
var t1 = context.Set<SingleTargetModel>().First();
即使用 DbContext.Set<T>,可以获取到一个数据加载集,当然也可以结合实体类的托管来一起使用。
那么为什么,我推荐使用配置类加载吗?
因为在实际开发中,一个完整的程序或者网站实体类都会大于 10,而这些如果使用属性的形式会非常多,不利于实际开发。而且,EF Core 可以通过 Assembly 方式整体加载配置文件。再者,为了保证 ORM 中的 O 不受其他因素的影响。也就是说,如果使用注解形式配置映射关系,那么势必会造成影响。
当然了,使用配置文件必然会导致项目的类增多,而且大量的重复类可能会出现。当然了,如果考虑到这个问题的话,可以试试写一个项目代码生成器哦,专门用来处理这些差不多的类。
咳咳,总而言之,使用配置文件利大于弊,所以我推荐使用配置文件对关系进行配置。
2. 数据变化
换句话说,嗯,也就是增删改。在数据增删这两方面,EF Core 没有太多需要注意的地方。不过如果有导航属性的话,在新增的时候,EF Core 会自动检索导航属性的另一端是否需要新增到数据库中,如果需要新增的话,EF Core 会自动标记为新增的。
而删除,如果在配置导航属性时,没有设置级联删除,删除当前元素,如果另一端的外键是可空类型的,并不会删除导航属性另一端的元素只会设置外键指向为 NULL,如果另一端外键是不可空的,那么就会同时删除。如果需要修改,可以使用以下方法修改,在配置导航属性的时候:
OnDelete(DeleteBehavior.Cascade);
对于可为 NULL 的外键来说,枚举 DeleteBehavior 的值起以下作用:
行为名称 | 对内存中的依赖项 / 子项的影响 | 对数据库中的依赖项 / 子项的影响 |
---|---|---|
Cascade | 删除实体 | 删除实体 |
ClientSetNull(默认) | 外键属性设置为 null | None |
SetNull | 外键属性设置为 null | 外键属性设置为 null |
Restrict | None | None |
而对于不可为 NULL 的外键来说,枚举 DeleteBehavior 的值起以下作用:
行为名称 | 对内存中的依赖项 / 子项的影响 | 对数据库中的依赖项 / 子项的影响 |
---|---|---|
Cascade(默认) | 删除实体 | 删除实体 |
ClientSetNull | SaveChanges 引发异常 | None |
SetNull | 引发 SaveChanges | SaveChanges 引发异常 |
Restrict | None | None |
而对于数据的修改,EF Core 的做法是通过监控实体的 ChangeTracker 来实现对数据实体的状态更新。也就是说,如果你从 EF Core 的上下文获取了一个实体对象,对这个对象的某些值进行了修改。这时候 EF Core 其实已经记录了这个对象的修改。不需要我们额外的调用修改方法(因为根本没有 Update 方法)。
EF Core 在我们调用 SaveChanges 会把缓存的所有更改(增、删、改)都推送给数据库。如果有一条数据变更因为数据库校验或者其他约束没有通过,就会报错,同时撤销所有已推送的变更并取消后续变更的推送。
从数据库的角度来看,EF Core 在 SaveChanges 的过程中是以事务的形式推送给数据库的。如果出错,那么事务就会回滚。
所以一般情况下,EF 不需要开启事务。
3. 花样查询
EF Core 支持 Linq 查询,所以在查询的时候可以使用 Linq 进行。简单示例如下:
var context = new DefaultContext("Data Source=demo.db");
var results = from t in context.Set<SingleTargetModel>()
select t;
当然,也可以使用方法链的形式传入一个 Expression<Func<T,bool>> 类型的表达式。
var results = context.Set<SingleTargetModel>().Where(t=>true);
看到这里了,可能会有疑问了,这明明很简单呀。是的,如果只是查询,自然简单。
那么,结合排序、分页之后呢?先来看看排序是怎么实现的吧。
在查询表达式写法中,排序应该这样的写的:
var results = from t in context.Set<SingleTargetModel>()
orderby t.Id //descending 如果降序则取消注释
select t ;
方法链的形式是:
var results = context.Set<SingleTargetModel>().Where(t=>true).OrderBy(t=>t.Id);
分页只能通过方法链的形式进行分页,这里提供一个分页的工具方法:
public static IQueryable<T> Paging<T>(IQueryable<T> source,int pageIndex,int pageSize)
{return source.Skip(pageSize * (pageIndex - 1)).Take(pageSize);
}
这里用到的是 Skip(int count) 表示忽略数据集的前 count 条记录,Take(int count) 取得数据集的前 count 条记录。
EF Core 在调用 ToList 的时候,会将已调用的方法和 Linq 转换成 SQL 语句,并正式向数据库发起查询。如果出现了在 Linq 中调用三方方法或者自己写的工具方法的话,可能会提示不受支持。
如果使用的 Linq 表达式,则没关系,EF Core 在遇到这种情况的时候,会把数据库里所有数据都加载到上下文中,再执行后续的查询等操作。
所以,为了高效的查询,在执行查询的时候,最好使用简单的查询条件。
4. 后续
EF Core 整体使用已经介绍完了,当然照例是普通工程级的内容。下一篇我给大家介绍一下 EF Core 剩下一些边角料,嗯。如果要深挖代码的话,得以后有机会了。
数据访问系列,EF Core 篇即将到一段落。待 EF Core 篇完成后,将带领一起去探索 Nhibernate 和 Dapper,SqlSugar 这三个 ORM 框架。
更多内容烦请关注我的博客《高先生小屋》