跟踪测试DbContext,向"不是真正的ORM"说拜拜

编程

FreeSql 发展到现在,已经有两种稳定的开发模式,以下先简单带过一下。后面才是本文的主题。

方法一:基于 helper 的方式,祼用;

dotnet add package FreeSql

提供 CodeFirst、DbFirst、丰富的表达式树、读写分离、AOP等功能支持;

方法二:基于 Repository + UnitOfWok 的方式;

dotnet add package FreeSql.Repository

这是一个扩展包,提供标准的 IRepository 接口定义与默认实现,以及 UnitOfWork 工作单元的支持,更可怕的是集成了局部/全局过滤器,实现租户、软删除等功能不在话下。

不相信吗?请看以下代码:

public IServiceProvider ConfigureServices(IServiceCollection services) {

services.AddSingleton<IFreeSql>(fsql);

services.AddMvc();

var builder = new ContainerBuilder();

builder.RegisterFreeRepository(filter => filter

.Apply<ISoftDelete>("SoftDelete", a => a.IsDeleted == false)

.Apply<ITenant>("Tenant", a => a.TenantId == 1)

);

builder.Populate(services);

var container = builder.Build();

return new AutofacServiceProvider(container);

}

比 abpvnext 还要方便,因为 abp 的相关实体需要实现接口 ISoftDelete、ITenant;

我们没有这个限制,只要过滤器的表达式解析成功,就算可用;

使用在任何实体上的时候,只要 [实体].IsDeleted == false 能解析能过,就算可用;

方式三:基于 DbContext

这个项目仍然是一个扩展包,提类似 EFCore 那样的开发习惯。目前定义的规则如下:

文字规则略显复杂,后边有代码演示,以及图文介绍在 sqlite 和 sqlserver 下的测试过程。

DbContext

  • 提供 SaveChanges 方法;
  • 执行队列;

DbSet

  • 提供 Add、AddRange、Remove、RemoveRange、Update、UpdateRange 方法;
  • 以及 Select 属性(连去原有的 FreeSql 查询对象);
  • 私有对象 states,存储实体的副本哈希集合,key=实体的主键值,value=实体;

Add/AddRange(entitys)

  • 验证 entitys 主键值,是否存在于 states 中,存在时报错;
  • 验证 entitys 主键中存在自增:

    • 若有,则立即开启 DbContext 事务,按数据库种类执行相应的方法,最终将返回的自增值,赋给entitys的属性;
    • 若无,并且 entitys 无主键值,则报错;
    • 否则,进入【打包执行队列】;

  • 完成时更新 states;

Remove/RemoveRange(entitys)

  • 验证 entitys 主键值,若无则报错;
  • 验证 states 中是否存在,若无则提醒应该先查询,再删除;
  • 删除 states 对应的实体;
  • 清除 entitys 内的自增属性值、Guid 类型的值,那这个 entitys 将变为可 Add 状态;
  • 进入【打包执行队列】;

Update/UpdateRange(entitys)

  • 验证 entitys 主键值,若无则报错;
  • 验证 states 中是否存在,若无则提醒应该先查询,再删除;
  • 进入【打包执行队列】;

Select

  • 立即执行队列中的命令(打包方式),以免脏读到未提交的数据;
  • 查询完成时,更新 states 的值;

更新数据规则

  • 对比 states 中存在的历史快照值,返回即将修改的 fields;

演示代码

using FreeSql;

public class SongContext : DbContext {

public DbSet<Song> Songs { get; set; }

public DbSet<Tag> Tags { get; set; }

protected override void OnConfiguring(DbContextOptionsBuilder builder) {

builder.UseFreeSql(这里是IFreeeSql对象);

}

}

public class Song {

[Column(IsIdentity = true)]

public int Id { get; set; }

public DateTime? Create_time { get; set; }

public bool? Is_deleted { get; set; }

public string Title { get; set; }

public string Url { get; set; }

}

public class Tag {

[Column(IsIdentity = true)]

public int Id { get; set; }

public string Name { get; set; }

}

using (var ctx = new SongContext()) {

ctx.Songs.Select.Where(a => a.Id > 10).ToList();

//查询结果,存入 states

var song = new Song { };

//可插入的 song

ctx.Songs.Add(song);

id = song.Id;

//因有自增类型,立即开启事务执行SQL,返回自增值

var adds = Enumerable.Range(0, 100)

.Select(a => new Song { Create_time = DateTime.Now, Is_deleted = false, Title = "xxxx" + a, Url = "url222" })

.ToList();

//创建一堆无主键值的数据

ctx.Songs.AddRange(adds);

//立即执行,将自增值赋给 adds 所有元素,因为有自增类型,如果其他类型,指定传入主键值,不会立即执行

for (var a = 0; a < adds.Count; a++)

adds[a].Title = "dkdkdkdk" + a;

ctx.Songs.UpdateRange(adds);

//批量修改,进入队列

ctx.Songs.RemoveRange(adds.Skip(10).Take(20).ToList());

//批量删除,进入队列,完成时 10-20 元素的主键值会被清除

//ctx.Songs.Update(adds.First());

adds.Last().Url = "skldfjlksdjglkjjcccc";

ctx.Songs.Update(adds.Last());

//单条修改 urls 的值,进入队列

//throw new Exception("回滚");

//ctx.Songs.Select.First();

//这里做一个查询,会立即打包【执行队列】,避免没有提交的数据,影响查询结果

ctx.SaveChanges();

//打包【执行队列】,提交事务

}

在 sqlite 测试

打个岔:为什么一条条的执行?

  • 有自增属性需要获取值;
  • sqlite 没有批量插入获取多个自增的办法,或者您有招来支一支(万分感谢);
  • 后面采用 sqlserver 测试,就不是这个境况了,insert into values(),(),(),然后利用 output 特性返回所有值;

    • 比较蛋疼的是,这个特性不是所有数据库都有

可以看见,最终 SaveChanges 时将不会产生影响的命令,一起打包执行,即采用优化合并的方式进行执行。

例如:

ctx.Songs.Update(adds[0]);

ctx.Songs.Update(adds[1]);

这两个更新操作,会合成一条 SQL 命令执行。

在 sqlserver 测试

其实大致与 sqlite 下相同,唯一的区别在于 AddRange 的处理方式,如图:

当插入单条时,采用了第一行代码的 SQL 命令;

当批量插入时,采用了后面看上去复杂的 SQL 命令;

所有传入的实体属性值在执行完成后,都会更新;

特别说明

FreeSql.DbContext 目前仍处于研究开发阶段,不适合商用;

总结

为什么写这篇文章,时常看见有人说某某 orm 不是真正的 orm,没有 OO 思想。

希望 FreeSql.DbContext 随着时间的积累,稳定性和成熟度有所提升,不久成为一个真正的 ORM。

有人会担心,我们第三方做的不靠谱,没有 EFCore 稳定的说话,这个是当然。

但是我们也有自己的特点,不是吗?我们可以做到多种数据库使用习惯的一致性,这点 EFCore 目前是没有办法解决的难题。

从细节出发,我们的口号是:做 .NETCore 最方便的 ORM!

github: https://github.com/2881099/FreeSql 377星

还请献上宝贵的一星,谢谢观看!!

以上是 跟踪测试DbContext,向"不是真正的ORM"说拜拜 的全部内容, 来源链接: utcz.com/z/510905.html

回到顶部