跟踪测试 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星

还请献上宝贵的一星，谢谢观看！！