FreeSQL

FreeSql (三十四)CodeFirst 迁移说明

僤鯓⒐⒋嵵緔 提交于 2020-08-06 11:24:21
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(); //请务必定义成

手把手撸套框架-ORM框架的选择

自作多情 提交于 2020-07-24 08:32:34
目录 一,为什么选择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 不能同日而语,但是

[LINQ2Dapper]最完整Dapper To Linq框架(一)---基础查询

 ̄綄美尐妖づ 提交于 2020-05-03 16:43:01
此框架是Dapper的扩展,效率优于EntityFramwork,并且支持.NetFramework和.NetCore框架 支持.net framework4.5.1,.net core2.0及以上,更低版本适配如.netFramework4.0及以下请加群下载 支持Mssql,Oracle,Mysql等数据库 应用层需要引用包Kogel.Dapper.Extension.MsSql(如果数据库是Oracle则引用Kogel.Dapper.Extension.Oracle),Nuget上可以下载安装。 或者使用Nuget命令添加包 Install-Package Kogel.Dapper.Extension.MsSql   目录 [LINQ2Dapper]最完整Dapper To Linq框架(一)---基础查询 [LINQ2Dapper]最完整Dapper To Linq框架(二)---动态化查询 [LINQ2Dapper]最完整Dapper To Linq框架(三)---实体类关系映射 [LINQ2Dapper]最完整Dapper To Linq框架(四)---Linq和SQL并行使用 [LINQ2Dapper]最完整Dapper To Linq框架(五)---查看Linq实际执行的SQL [LINQ2Dapper]最完整Dapper To Linq框架(六)--

上周热点回顾(1.21-1.27)

做~自己de王妃 提交于 2020-04-27 19:39:32
热点随笔: · 几行c#代码,轻松搞定一个女大学生 ( 鱼丸粗面一碗 ) · 犹豫了许久,还是写个年总结记录一下吧 ( 邹琼俊 ) · 写给程序员的裁员防身指南 ( 陈树义 ) · 人人都爱写总结, 却少有人做计划 ( sherrywasp ) · 2018——而立之年 ( 左潇龙 ) · 乡下人回忆录之——2019的年前年后 ( 彪悍的代码不需要注释 ) · 一分钟搞懂你的博客为什么没人看 ( 鱼丸粗面一碗 ) · 【纯技术贴】.NETStandard FreeSql v0.0.9 功能预览 ( nicye ) · 自己动手用electron+vue开发博客园文章编辑器客户端【二】 ( liulun ) · 面试:“我最大的缺点是追求完美”,你当面试官是傻子!! ( 闲鱼君 ) · 从拼多多优惠券事件看到的一些反思 ( 腾讯云+社区 ) · Spire高效稳定的.NET组件 ( 山治先生 ) 热点新闻: · 1年收割20亿智商税的小罐茶之父:我已经“骗”了你们5次! · 搜索引擎百度已死:沦为替百家号导流的工具 · 马云:我从来不看大学文凭 这个不太重要 · 我去婚恋网站逛了逛,发现全是TM的骗子 · 传程序员锁死服务器搅黄游戏 600万打水漂 创始人负债数百万 · 崔永元:盘盘百度! · 《百度已死》作者:百度股价大跌非文章直接引发|百度回应 · 火车票再见

FreeSql 已支持 .NetFramework 4.0、ODBC 访问

*爱你&永不变心* 提交于 2020-04-18 06:27:37
FreeSql 开源发布快一年了,目前主仓库代码量 64118 行,用 git 命令统计的命令如下: find . "(" -name "*.cs" ")" -print | xargs wc -l 加上其他几个扩展包的代码,大约有 70000 行源码。 仓库地址: https://github.com/2881099/FreeSql 在金九银十的日子,发布了两大重要支持更新,分别是 .NetFramework4.0 和 ODBC。 随着不断的迭代更新,越来越稳定,也越来越强大。预计在一周年的时候(2020年1月1日)发布 1.0 正式版本。 由于篇幅原因,太短则上不了首页,同时也对不起观众,下面介绍一下最近更新的几个较实用的功能: ISelect.ToDelete/ToUpdate IFreeSql 之 CRUD 方法,分别对应 IInsert、ISelect、IUpdate、IDelete。 IDelete 默认不支持导航对象,多表关联等。ISelect.ToDelete 可将查询对象转为删除对象,以便支持导航对象或其他查询功能删除数据,如下: fsql.Select<T1>().Where(a => a.Options.xxx == 1).ToDelete().ExecuteAffrows(); 注意:此方法不是将数据查询到内存循环删除,上面的代码产生如下 SQL 执行:

FreeSql 导航属性的联级保存功能

我的未来我决定 提交于 2020-04-18 05:42:36
写在前面 FreeSql 一个款 .net 平台下支持 .net framework 4.5+、.net core 2.1+ 的开源 ORM。单元测试超过3100+,正在不断吸引新的开发者,生命不息开发不止。 和 EFCore 一样,我们也有导航对象,支持【OneToOne】(一对一)、【ManyToOne】(多对一)、【OneToMany】(一对多)、【ParentChild】(父子)、【ManyToMany】(多对多),可以约定配置或手工配置实体间的关联,也可以使用 fluent api 设置关联。 联级保存功能可实现保存对象的时候,将其【OneToMany】、【ManyToMany】导航属性集合也一并保存,本文档说明实现的机制防止误用。 机制规则 【一对多】模型下, 保存时可联级保存实体的属性集合。出于使用安全考虑我们没做完整对比,只实现实体属性集合的添加或更新操作,所以不会删除实体属性集合的数据。 完整对比的功能使用起来太危险,试想下面的场景: 保存的时候,实体的属性集合是空的,如何操作?记录全部删除? 保存的时候,由于数据库中记录非常之多,那么只想保存子表的部分数据,或者只需要添加,如何操作? 【多对多】模型下,我们对中间表的保存是完整对比操作,对外部实体的操作只作新增(注意不会更新) 属性集合为空时,删除他们的所有关联数据(中间表) 属性集合不为空时

[分享] 一款极简单的 BaseEntity CRUD 方法

醉酒当歌 提交于 2020-04-18 05:42:07
前言 尝试过 ado.net、dapper、ef,以及Repository仓储,甚至自己还写过生成器工具,以便做常规CRUD操作。 它们日常操作不方便之处: 每次使用前需要声明,再操作; 很多人一个实体类,对应一个操作类(或DAL、DbContext、Repository); BaseEntity 是一种极简单的 CodeFirst 开发方式,特别对单表或多表CRUD,利用继承节省了每个实体类的重复属性(创建时间、ID等字段),软件删除等功能,进行 crud 操作时不必时常考虑仓储的使用; 本文介绍 BaseEntity 一种极简约的 CRUD 操作方法。 功能特点 自动迁移实体结构(CodeFirst),到数据库; 直接操作实体的方法,进行 CRUD 操作; 简化用户定义实体类型,省去主键、常用字段的配置(如CreateTime、UpdateTime); 实现单表、多表查询的软删除逻辑; 声明 示范项目: https://github.com/2881099/FreeSql/tree/master/Examples/base_entity 参考 BaseEntity.cs 源码(约100行),拷贝项目中使用,然后添加 nuget 引用包: dotnet add package FreeSql.Repository dotnet add package FreeSql

[开源] FreeSql.Tools Razor 生成器

我们两清 提交于 2020-04-18 04:46:29
FreeSql 经过半年的开发和坚持维护,在 0.6.x 版本中完成了几大重要事件: 1、按小包拆分,每个数据库实现为单独 dll; 2、实现 .net framework 4.5 支持; 3、同时支持 MySql.Data、MySqlConnector 的实现; 4、自定义导航属性关系的配置; 5、配套工具 FreeSql.Tools 发布; 本文主要讲解第5项,大主角往往在最后才出现!!! 拆分小包 在此之前一直被吐槽 FreeSql 臃肿,没有小包开发理念。其实我是一点也不承认这种评价,虽然刚开发只有一个 FreeSql.dll,但是在开发和规划上简单了很多。 有一条开发原则讲道:过早优化是恶梦! 大概意思是无论做什么项目,不要想着一开始就过度系统的、规范的执行。从外界来看是正规了,但是进度和稳定性会大大折扣。可以不信我,但是请一定要相信前人的总结啊!!! 从之前的一个 dll 到拆分成小包,我们总共耗时两天,虽然都在一个项目内开发,但其实耦合性并不高。 车到山前必有路,时机到了自然会拆。这个时机也是奠定 FreeSql 走出了稳定关键的一步。这样就会有更多人愿意加入 FreeSql 阵营。 各数据库单独包、延时加载包; FreeSql.Extensions.LazyLoading FreeSql.Provider.MySql FreeSql.Provider

FreeSql 新手上路系列教程已发布在 cnblogs

穿精又带淫゛_ 提交于 2020-04-18 03:44:59
FreeSql 是一个功能强大的对象关系映射程序(O/RM),支持 .NETCore 2.1+ 或 .NETFramework 4.5+(QQ群:4336577) FreeSql采用MIT开源协议托管于 github,地址:( https://github.com/2881099/FreeSql )[ https://github.com/2881099/FreeSql ] FreeSql 从 2018 年 11 月底开始研发,在 2019 年元旦开源,整体来说功能的完善度已经相当OK。 由于之前的功能可能存在变动性,不宜将文档四处发布,避免功能更新后文档未及时同步更新的问题。 文档之前一直采用 github wiki 的方式,现正式在 cnblogs 博客园上建专号维护相关文档。 第一个系列《FreeSql 新手上路》系列文章数量 35 篇已发布,希望能帮助有需要的朋友学习 FreeSql。 (一)入门 (二)自动迁移实体 (三)实体特性 (四)实体特性 Fluent Api (五)插入数据 (六)批量插入数据 (七)插入数据时忽略列 (八)插入数据时指定列 (九)删除数据 (十)更新数据 (十一)更新数据 Where (十二)更新数据时指定列 (十三)更新数据时忽略列 (十四)批量更新数据 (十五)查询数据 (十六)分页查询 (十七)联表查询 (十八)导航属性 (十九)多表查询

在 EFCore 定义的实体中进行 FreeSql 开发

和自甴很熟 提交于 2020-04-18 03:44:44
EFCore 和 FreeSql 都是 ORM,在各自领域都有着独特的优势。 问题起源 假设某项目是使用 EFCore 开发的,且实体 特性或FluentApi 都配置好了,如: protected override void MapTable( EntityTypeBuilder builder ) { builder.ToTable( "cg_kssqbs" ); //实体表名有单独定义 } 此时用 FreeSql 操作实体会报错:数据库表不存在。除非又配置一套FreeSql的 特性或FluentApi,这显然会比较麻烦。 问:为什么不统一,非要各自定义标准? 答:每个 ORM 的理念不同,提供的功能也不尽相同,FreeSql 的理念是“打造 .NETCore 最方便的 ORM”。与 EFCore 相比只提供了极少的特性配置(如:主键、自增、类型、别名、可空),并且这些设定针对已现实的数据库都是一致的。因此 FreeSql 有单独一套简单的实体配置语法,特别声明:方便、简单指的是上手简单,并非说 FreeSql 功能简单。 来自 Issues 4 《建议能结合EF Core的一些特性来弄 #4》 解决方法 1、关闭 FreeSql 迁移功能 IFreeSql fsql = new FreeSql.FreeSqlBuilder() .UseConnectionString