FreeSQL

目录 一，为什么选择SqlSugar？ 在.net core ORM框架中，能选择的方案其实有很多，包括以下方案： 1，EF-Core 2，Dapper 3，FreeSql 4，SqlSugar 为什么最后选择了Sqlsugar 呢？ 一个个来说， 首先是: EF-core 。 EF-core 一开始想法也是担心性能问题，大概在7年前 有尝试过一次EF，深深被EF的性能所折服 实在是太慢了，当然做一些小型项目，EF当然是体现不出性能差距的，但是谁又知道自己的“小项目”哪天不会随着 业务的发展变成“大项目” 呢？ 所以，一开始对EF 以及EF-Core 没有好感，不过后来看了，EF-Core的官网介绍， 感观上发生了很大的变化， 总的来说就是： EF 和 EF-Core 完全是两个东西。 更准确的说是：.net Core 和 .net Famework 完全是两个东西。 这么说吧, .net Core在性能上完全不怂 java，go，python，php 任何一种语言，再说.net 性能不好的，可以啪啪打脸了。 但是，我还是首先淘汰了，EF-Core。原因是，查百度各种ORM都拿EF-core 做性能测试，可以参考以下连接： 参考： https://www.cnblogs.com/kellynic/p/10557882.html 虽然，EF-Core 性能跟EF 不能同日而语，但是

C# 数据操作系列 - 19 FreeSql 入坑介绍 前言 前几天FreeSql的作者向我推荐了FreeSql框架，想让我帮忙写个文章介绍一下。嗯，想不到我也能带个货了。哈哈，开个玩笑～看了下觉得设计的挺有意思的，所以就谢了这篇文章。 简单介绍一下，FreeSql 是NCC组织的沙盒级项目，是一款功能强大的 ORM 组件，支持 .NET Core、.NET Framework 和 Xamarin。目前 FreeSql 支持以下数据库：MySQL、PostgreSQL、SqlServer、Oracle、Sqlite、Odbc、微软 Access 以及国产数据库达梦。 也就是说也是一个由国内优秀开发者维护的优秀项目，初步看了下功能很齐全。小伙伴们有时间可以取瞅瞅。下图是我从它GitHub仓库里复制过来的。可以看见支持的功能还是相当多的。 关于NCC社区，是.net core的一个开源社区，也是国内最大的.net core开源社区 初步使用 照例，没安装就没有调用。所以，在创建项目之后，安装一下吧： dotnet add package FreeSql 然后创建一个IFreeSql对象： public class FreeSqlContext { public static IFreeSql FreeSqlConnect { get; } = new FreeSql

简介 FreeSql.Connection.Extensions 这是 FreeSql 衍生出来的扩展包，实现（Mysql/postgresql/sqlserver/Oracle/SQLite）数据库连接对象扩展方法，像 Dapper 一样的使用习惯。QQ群：4336577(已满)、8578575(在线) 快速上手 dotnet add package FreeSql.Connection.Extensions 测试实体类 class TestConnectionExt { public Guid id { get; set; } public string title { get; set; } public DateTime createTime { get; set; } = DateTime.Now; } 查询 和 FreeSql 一样的查询方法。 using (var conn = new MySqlConnection(_connectString)) { var list = conn.Select<TestConnectionExt>().Where(a => a.id == item.id).ToList(); } 插入 和 FreeSql 一样的插入方法。 using (var conn = new MySqlConnection(_connectString)

FreeSql 项目大概在20天前想着要做的，今天发布0.0.4在群里被一位大神讽刺。 这位无名氏哥们的观点，先声明这不是找安慰的文章，更加不是报复打击的目的。 1 所以这个比EF好在哪里 2 毕竟EF是官方的技术，你自己造的轮子得说明自己哪里不是重复造轮子，而不是问已有的轮子到底怎么样 3 EF完全可以胜任并且超出一个ORM框架需要的所有功能 4 你可以觉得EF不够好，自己做一个更好的，但是这建立在你能指出EF哪里不好的前提下 5 另外插入一个话题，[图片]这个项目引用 很显然 这违背了.NET Core的小包思想，四个字，按需引用 6 这根本就不是什么拆包的问题，而是在开发的时候就是小包，你不了解.NET Core的思想，每必要非得说自己是正确的，有人教你，你就虚心接受，没什么大不了的 7 你target了.NET Standard，却走的是原来的那一套思路， 8 在接受一个新的平台的时候，你需要接受它的思想 9 不要重复造轮子，你如果觉得ef有缺陷，哪不好，自己提issue，给pull request，如果你觉得ef一无是处，你自己做，那也得说明它比ef好在哪里，是吧 10 你和ef的区别在于你把sql语句暴露出来了，而ef是使用IQueryable来完全封装sql的 11 IQueryable是一个标准接口，你要标新立异，本来就是兼容性很差的 12

目录 在之前的随笔中： 　1.1： ORM的选择 　1.2： SqlSugar的搭建与避坑 分别有讲过SqlSugar 和 FreeSql，我最后选用了Sqlsugar，今天又写一遍，放弃SqlSugar 转用FreeSql。 起始，说起来有点啪啪打脸的意思， 但其实不是。 写第一篇 ORM的选择的时候 大约是两个月前，只是最近发到博客园。 当时的情况就是，急需一个ORM框架快速上手做开发，现在两个月过去了。我到新公司开发的第一个项目，也结束了。 虽然不算深度使用SqlSugar，但是 也算是 熟悉了。 确实对于新手刚入坑的来说，sqlsugar是最简单，容易上手的，但是用一段时间就会发现了 sqlsugar的短板还是比较明显。 第一，编写风格。 尤其是在连表查询的时候，sqlsugar 的风格老是感觉怪怪的： 对比，FreeSql 则用起来 舒爽很多： 第二： 稳定性 这里，Freesql 目前不算深度使用，但是写过一两个demo，感觉还是很不错。 但是Sqlsugar 在之前项目的使用中 有遇到过，Update 数据失败的问题，使用的是Oracle 数据库，用的是SimpleClient ，不是每张表都失败，有的表修改能成功。 这里我没有去详细排查 究竟是以为哪个字段有问题还是这么，后来为了避免这种问题，全部使用的 SqlSugarClient，同样的表

关于无限级分类 第一种方案： 使用递归算法，也是使用频率最多的，大部分开源程序也是这么处理，不过一般都只用到四级分类。 这种算法的数据库结构设计最为简单。category表中一个字段id，一个字段fid(父id)。这样可以根据WHERE id = fid来判断上一级内容，运用递归至最顶层。 分析：通过这种数据库设计出的无限级，可以说读取的时候相当费劲，所以大部分的程序最多3-4级分类，这就足以满足需求，从而一次性读出所有的数据，再对得到数组或者对象进行递归。本身负荷还是没太大问题。但是如果分类到更多级，那是不可取的办法。 这样看来这种分类有个好处，就是增删改的时候轻松了…然而就二级分类而言，采用这种算法就应该算最优先了。 第二种方案： 设置fid字段类型为varchar，将父类id都集中在这个字段里，用符号隔开，比如：1,3,6 这样可以比较容易得到各上级分类的ID，而且在查询分类下的信息的时候， 可以使用：SELECT * FROM category WHERE pid LIKE “1,3%”。 分 析：相比于递归算法，在读取数据方面优势非常大，但是若查找该分类的所有 父分类 或者 子分类 查询的效率也不是很高，至少也要二次query，从某种意义看上，个人觉得不太符合数据库范式的设计。倘若递增到无限级，还需考虑字段是否达到要求，而且 在修改分类和转移分类的时候操作将非常麻烦。

目录 在之前的随笔中： 　1.1： ORM的选择 　1.2： SqlSugar的搭建与避坑 分别有讲过SqlSugar 和 FreeSql，我最后选用了Sqlsugar，今天又写一遍，放弃SqlSugar 转用FreeSql。 起始，说起来有点啪啪打脸的意思， 但其实不是。 写第一篇 ORM的选择的时候 大约是两个月前，只是最近发到博客园。 当时的情况就是，急需一个ORM框架快速上手做开发，现在两个月过去了。我到新公司开发的第一个项目，也结束了。 虽然不算深度使用SqlSugar，但是 也算是 熟悉了。 确实对于新手刚入坑的来说，sqlsugar是最简单，容易上手的，但是用一段时间就会发现了 sqlsugar的短板还是比较明显。 第一，编写风格。 尤其是在连表查询的时候，sqlsugar 的风格老是感觉怪怪的： 对比，FreeSql 则用起来 舒爽很多： 第二： 稳定性 这里，Freesql 目前不算深度使用，但是写过一两个demo，感觉还是很不错。 但是Sqlsugar 在之前项目的使用中 有遇到过，Update 数据失败的问题，使用的是Oracle 数据库，用的是SimpleClient ，不是每张表都失败，有的表修改能成功。 这里我没有去详细排查 究竟是以为哪个字段有问题还是这么，后来为了避免这种问题，全部使用的 SqlSugarClient，同样的表

目录 在之前的随笔中： 　1.1： ORM的选择 　1.2： SqlSugar的搭建与避坑 分别有讲过SqlSugar 和 FreeSql，我最后选用了Sqlsugar，今天又写一遍，放弃SqlSugar 转用FreeSql。 起始，说起来有点啪啪打脸的意思， 但其实不是。 写第一篇 ORM的选择的时候 大约是两个月前，只是最近发到博客园。 当时的情况就是，急需一个ORM框架快速上手做开发，现在两个月过去了。我到新公司开发的第一个项目，也结束了。 虽然不算深度使用SqlSugar，但是 也算是 熟悉了。 确实对于新手刚入坑的来说，sqlsugar是最简单，容易上手的，但是用一段时间就会发现了 sqlsugar的短板还是比较明显。 第一，编写风格。 尤其是在连表查询的时候，sqlsugar 的风格老是感觉怪怪的： 对比，FreeSql 则用起来 舒爽很多： 第二： 稳定性 这里，Freesql 目前不算深度使用，但是写过一两个demo，感觉还是很不错。 但是Sqlsugar 在之前项目的使用中 有遇到过，Update 数据失败的问题，使用的是Oracle 数据库，用的是SimpleClient ，不是每张表都失败，有的表修改能成功。 这里我没有去详细排查 究竟是以为哪个字段有问题还是这么，后来为了避免这种问题，全部使用的 SqlSugarClient，同样的表

前言 ： 深圳漂泊十年，三个阶段： 第一阶段：20-23岁，技术快速提升，收入也快速提升，那几年几乎没有什么思想负担，做好技术就行。 第二阶段：23-26岁，开始有思想负担，尤其恐惧程序员30岁那一道劫难，现在互联网也有说35岁的。遂转型做管理。 第三阶段：26岁-29岁，一直在小公司做管理，专业技能已荒废，管理又没有真正的接触过大公司的熏陶，遂开始创业。 最终创业失败，响应深圳的号召： 来了就是惠州人！ 转战惠州，定居惠州。 不再做那些一夜暴富的梦，短期内页不再考虑创业，缓几年把家庭开支稳住。重新找一份程序员的工作， 没有找管理工作，因为局限于我的管理水平，在真正的大公司行不通，我也不想去那些三年就不见了的小公司，这些年劳动仲裁官司都打过两次了！ 至此：人到中年不得意。。。 30岁重新学.net，重新学core。手把手撸一套框架，思想依然源于： Winner框架 。 取名： Victory 《目录》 1，ORM: 　　1.1： ORM的选择 　　1.2： SqlSugar的搭建与避坑 　　1.3： 放弃SqlSugar 转用 FreeSql　 2，代码生成器： 　　2： 代码生成器 （VictoryCode） 3，项目模板 　　3.1：Vue-Admin （空） 　　3.2：Vue-Admin（登录） 　　3.3：Vue-Admin（登录+权限） 　　3.4：AdminLte

FreeSql 支持 CodeFirst 迁移结构至数据库，这应该是(O/RM)必须标配的一个功能。 与其他(O/RM)不同FreeSql支持更多的数据库特性，而不只是支持基础的数据类型，这既是优点也是缺点，优点是充分利用数据库特性辅助开发，缺点是切换数据库变得困难。不同程序员的理念可能不太一致，FreeSql尽量把功能支持到极致，至于是否使用是项目组技术衡量的另一个问题。 尽管多种数据库适配逻辑非常复杂，FreeSql始终秉承优化程序开发习惯的原则尽量去实现，中间碰到了一些非技术无法攻克的难题，比如数据库的自定义类型，和实体类本身就是一种冲突，为了减少使用成本，诸如此类的数据库功能没有得到支持。 static IFreeSql fsql = new FreeSql.FreeSqlBuilder() .UseConnectionString(FreeSql.DataType.MySql, "Data Source=127.0.0.1;Port=3306;User ID=root;Password=root;Initial Catalog=cccddd;Charset=utf8;SslMode=none;Max pool size=10") .UseAutoSyncStructure(true) //自动同步实体结构【开发环境必备】 .Build(); //请务必定义成