标签：LiteSql DBHelper ORM https Dapper 100 轻量级
之前写的DBHelper，名称确实太Low，就改了个名，叫LiteSql，本来想叫SqlShuttle(SQL一把梭)，奈何单词太长。
有两个版本，一个是LiteSql，一个是Dapper.LiteSql，LiteSql底层用的是ADO.NET，Dapper.LiteSql底层用的是Dapper，提供的接口和功能是一样的。
Dapper.LiteSql算是Dapper扩展。
简介
一款使用原生SQL查询的轻量级ORM，支持Oracle、MSSQL、MySQL、PostgreSQL、SQLite、Access数据库。
代码来源
代码来源于需求，我整个职业生涯待过的公司，要么用NHibernate要么用DBHelper，NHibernate我很讨厌，所以就折腾DBHelper了。原始版本的四个主流数据库的DBHelper，都是经历过实际项目的，不过现在除了自己写程序或小项目，我自己没有机会用了，没有需求就没有新功能，最近也只加了个手动分表的支持。
文档
https://gitee.com/s0611163/LiteSql/blob/main/README.md
https://gitee.com/s0611163/Dapper.LiteSql/blob/main/README.md
NuGet
https://www.nuget.org/packages/LiteSql
https://www.nuget.org/packages/Dapper.LiteSql
为什么用LiteSql
并非推荐大家用，但我相信会有人需要的，所以有必要写这个博客自荐一下。
EF和EFCore虽然我写过Demo，但我只能说我不了解。FreeSql和SqlSugar是语法糖的代表，功能很多很强大，语法糖最重要的是要尽量符合使用习惯，使大家尽量不看文档，就能猜出来怎么用，在这方面FreeSql和SqlSugar很难超越，所以没必要重复造轮子，除非有人觉得可以超越。SmartSQL类似Java的MyBatis。Dos.ORM我也看了一下，好像跟上述两款同一类型。
Dapper不带扩展肯定不好用，要是100多个字段的表能写死人。Dapper.Contrib遇到数据库字段名和属性名不一致的情况还得自己想办法，DapperExtensions要写Mapping，那就是在用了扩展的情况下，自己再写个小扩展。有人写Demo就不考虑100多个字段的情况，我知道你可能有自动生成的工具，你不说，就是没有。
后续的话，对标FreeSql、SqlSugar那是不可能了，理念不同。能成为DBHelper的终级版或者Dapper扩展的终极版就很好了，这是需要首先进行科学论证的，我想EFCore肯定是经过科学论证的，这里的科学家是指微软的顶级大牛们。你说Dapper.Contrib有15M的下载量，怎么就不解决一下字段名和属性名不一致的情况，是什么理念导致的？DapperExtensions要写Mapping，减少对实体类的侵入性，肯定是一种理念，但100个字段我该怎么写，用什么方案？
对于这个ORM，现在的问题是，我没有用C#写增删改查的机会了，所以我不知道有什么需要改进的地方，空想是想不出来的。我是希望有人共同维护，但一定要有理念和边界，不是什么功能都可以加，不然的话为什么Dapper功能那么少？
怎么用？
怎么用请看文档。这里我只说一点。
在我上家公司用OracleHelper或SqlServerHelper的时候，查询、分页查询是一种固定写法，适应性广，我觉得很好，代码结构非常清晰，很容易看懂和维护。
标签：LiteSql,DBHelper,ORM,https,Dapper,100,轻量级 来源： https://www.cnblogs.com/s0611163/p/16553601.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。