网站配色案例分析,买淘宝店,建筑人才网简历,献县网站前言现在的项目#xff0c;在操作数据库的时候#xff0c;我都喜欢用ORM框架#xff0c;其中EF是一直以来用的比较多的#xff1b;EF 的封装的确让小伙伴一心注重业务逻辑就行了#xff0c;不用过多的关注操作数据库的具体细节。但是在某些场景会选择执行SQL语句#xff… 前言现在的项目在操作数据库的时候我都喜欢用ORM框架其中EF是一直以来用的比较多的EF 的封装的确让小伙伴一心注重业务逻辑就行了不用过多的关注操作数据库的具体细节。但是在某些场景会选择执行SQL语句比如一些复杂的插入或报表查询等其实不管用什么方式执行SQL语句防止SQL注入是必须的所以就有了下面的讨论。正文1. 先来个EF Core执行SQL演示1.1 准备一个EF Core的项目关于EF Core在项目中的使用之前分享了一篇很详细的文章这里就不重复说了详细内容请看这里《跟我一起学.NetCore之EF Core 实战入门一看就会》1.2 执行原生SQL前提已经生成数据库并且有对应的表(以下只是模拟演示并不是真实场景)在操作数据库时执行如下SQL有很多小伙伴看到这时应该也会怀疑这里会有SQL注入的风险因为这里的SQL语句看上去就是一个拼接的字符串只是用了插值运算符的形式好像没什么特别。1.2 打印日志查看真正执行的SQL表面看上去的确会有风险既然说没有那就拿出证据证明直接把EF执行过程的日志打印出来看看真正执行的SQL语句是什么样子EF Core好像在5.0之后就提供了一个便捷的配置可以方便的打印对应的SQL记录所以先来开启日志打印功能开启日志之后执行一下程序看看执行的真正SQL是什么样的控制台可以看到如下日志可以看到SQL语句已经参数化了所以是没有注入风险的。那到底是为什么呢因为ExecuteSqlInterpolatedAsync中的SQL语句参数的类型是FormattableStringEF Core内部根据FormattableString结果将对应的字符串生成参数化的SQL语句。2. FormattableString有点料为了看看FormattableString的作用建一个简单的控制台程序看看情况如下可以看到FormattableString中包含拼接的字符串和对应的参数拿到这些结果就可以构造成想要的结果了。2.1 var使用时还是要稍微注意一下之前一个项目因为var的使用线上出现一个bug挨个看了代码感觉都没问题而且开发和测试环境正常但在线上就是有问题最后通过模拟线上数据调试才搞定。大概使用如下image-20220314232802714之所以开发和测试环境没有问题是没有模拟全线上环境所以让这个bug漏掉了对于开发来说var用起来的确很是方便但对于类似于上面的场景使用具体的类型会避免一些不必要的Bug代码比较简单就不提交了~~~总结在开发过程中稍微一个小细节的改动可能效果就不一样同样一个小细节的忽视就可能带来一个很不好排查的Bug所以小伙伴开发过程中一定要注意哦关注“Code综艺圈”和我一起学习吧。
