读书人

[散分]送新人,为什么不推荐这样写,这样

发布时间: 2012-01-03 22:16:07 作者: rapoo

[散分]送新人,为什么不推荐这样写,这样写有啥问题?
如下代码

C# code
protected void GridView1_RowUpdating(object sender, GridViewUpdateEventArgs e)    {        string sqlstr = "update Patients set P_Name='"        //    + ((TextBox)(GridView1.Rows[e.RowIndex].Cells[1].Controls[0])).Text.ToString().Trim() + "',ID_Card='"            + ((TextBox)(GridView1.Rows[e.RowIndex].Cells[3].Controls[0])).Text.ToString().Trim() + "',Guardian_Name='"            + ((TextBox)(GridView1.Rows[e.RowIndex].Cells[4].Controls[0])).Text.ToString().Trim() + "' where PatientID='"            + GridView1.DataKeys[e.RowIndex].Value.ToString() + "'";        sqlHp.SQLExecute(sqlstr);        GridView1.EditIndex = -1;        bind();    }


为什么不推荐这样写,这样写有啥问题?


[解决办法]
不安全也不高效啊,而且要是改动的话也不方便改啊,不清楚
[解决办法]
1.ToString()没有考虑空值处理
2.注入式攻击
[解决办法]
我会用存储过程




[解决办法]
很容易被注入,比如第一个 TextBox 的值为 5'--
你的 P_Name 就全为 5 了。

[解决办法]
UP
[解决办法]
sdm
[解决办法]
应该主要就是安全的问题
[解决办法]
ding
[解决办法]
可读性比较差吧
[解决办法]
安全的问题
[解决办法]
建议用存储过程

安全!
[解决办法]
回帖是一种美德
[解决办法]
这样写的话,有一处改动就会需要改很多地方。
[解决办法]
不方便读写..你这样简单的还好说..复杂的判断的 就很难知道程序运行的本身SQL是什么了..
不如写好参数使用SqlParameter 这样SQL语句很清晰.很容易知道程序最终要去执行什么.不必去断点到最后才知道SQL是什么。

[解决办法]
jf
[解决办法]
这样写有被注入式攻击的危险,需要手动过滤参数,不如写成存储过程来的方便。
[解决办法]
建议LZ从头到尾些个最规范的出来学习下哈
[解决办法]
应该用SqlParameter。
[解决办法]
探讨
不方便读写..你这样简单的还好说..复杂的判断的 就很难知道程序运行的本身SQL是什么了..
不如写好参数使用SqlParameter 这样SQL语句很清晰.很容易知道程序最终要去执行什么.不必去断点到最后才知道SQL是什么。

[解决办法]
建议用存储过程。

可读性一般。
[解决办法]
主要还是安全性,不是可读性问题吧
[解决办法]
按照LZ的意思应该强调的不是安全方面的问题吧!

string是比较特殊的类型,按照string不可变性
C# code
string  str="a"+"b"+"c"; 


[解决办法]
不好修改 安全性不高
[解决办法]
一直这么写
[解决办法]
跟着前辈走没错
[解决办法]
容易被SQL注入,安全性不高,代码长,不容易修改
[解决办法]

探讨
回贴有感,有大感,点这儿看原贴

[解决办法]
SQL能注入式攻击的
[解决办法]
探讨
大家不必贴代码修正,
只要讨论即可,
有不妥的,或不科学的,不够严谨的都可以说,
仅指出来即可,分均分,越全面越好
以自勉和提高

[解决办法]
1.ToString()没有考虑空值处理
2.注入式攻击
[解决办法]
呵呵 学习学习 路过
[解决办法]
1,不便于维护
2,sql注入
[解决办法]
太难读了!
[解决办法]
感觉注入攻击严重
[解决办法]
探讨
主要还是安全性,不是可读性问题吧

[解决办法]
jf
[解决办法]
我也说下
1,用Cells[X]的处理方法在列排列顺序改变后也得改动程序.
2,UI和数据处理建议分开.
3,直接拼SQL的方式容易被注入攻击,建议用参数.

[解决办法]
安全性不高!
[解决办法]
没有考虑安全性!
[解决办法]
探讨
按照LZ的意思应该强调的不是安全方面的问题吧!

string是比较特殊的类型,按照string不可变性

C# codestring str="a"+"b"+"c";



内存中会存在"a"、"b"、"c"、"ab"、"abc"几个对象,而除了"abc"都是临时对象,会增大GC的压力!

使用StringBuilder或String.Format就不存在这种现象!


C# codestring str = String.Format("{0}{1}{2}","a","b","c");




不对请指出,谢谢

[解决办法]
探讨
1.ToString()没有考虑空值处理
2.注入式攻击

[解决办法]
代码安全性差
[解决办法]
jf
[解决办法]
探讨
1.ToString()没有考虑空值处理
2.注入式攻击

[解决办法]
源比大
[解决办法]
路过看看~!~
[解决办法]
安全型差、效率低。。。。。
[解决办法]
1. 可读性差


2. 易被注入攻击
3. 对相关的对象没有做空值及转换失败的判断处理
[解决办法]
看看
[解决办法]
代码安全性、可读性较差,sql注入!
[解决办法]
汗啊。
[解决办法]
因为没有用到参数传入
[解决办法]
不安全,4楼解释的很对
[解决办法]
不易於啊。
我得是用多架好~!
清晰明了
[解决办法]
现在已经很少有人这样写了吧。建议用存储过程。还有。如果换成我要这样写的话。
我肯定用strsql.append("");来写,也比较方便。省得用+“”之类的东西了
[解决办法]
帮顶。
[解决办法]
不安全
也很难扩展

我一般都是写到存储过程中,采用传参的方式
[解决办法]
扩展性,安全性,执行效率问题。通过存储过程和操作类实现
[解决办法]
这样写的原因 还不是因为看了书.....那些教程上,入门与提高上, 都这么干...
思想就被绑住了.

加入教材上不是那么写的, 我们又何必绕这么大个弯子呢?

写教材的人啊, 拿俺们当悟空了.


[解决办法]

[解决办法]

那位达人再去我的帖子上看下, 解决个问题? 在此谢过了!
[解决办法]
han a
[解决办法]
jf
[解决办法]
学习接分
[解决办法]
用3层来开发在项目复杂的情况下更易于维护
[解决办法]
总觉得不妥....学习...
[解决办法]
我是新人,新到看不懂lz的程序……
[解决办法]

探讨
扩展性,安全性,执行效率问题。通过存储过程和操作类实现

[解决办法]
可读性很差,并且要改起来太麻烦,时间久了估计自己看着都会晕乎的……
[解决办法]
呵呵 学习学习
[解决办法]
不知道!
这种情况应该是在要求多的时候才有需要区别。
[解决办法]
高手散分,新手接!激励自己~
[解决办法]
这是啥呢
[解决办法]
可读性差
[解决办法]
如果碰到个垃圾老板,就这样写是正解了

如果老板还不错,这样写,对不起老板,更对不起下一个维护代码的同行
[解决办法]
dddddddddd
[解决办法]
不安全不灵活
[解决办法]
UP
------解决方案--------------------


太难读了.
给你 几个个建议,.


一个是写成这样的方式...

C# code
     delete from [Booking] where PatientID=@PatientID;
[解决办法]
帮定 & 接分
[解决办法]
谁教我哈sql注入及注入后是什么情况
[解决办法]
这样写最大的问题是 如果有特殊符号比如说是 ’ 单引号的话 就会出现错误。 所以不推荐这样写 最好是用参数代替!
[解决办法]
探讨
呵呵 学习学习

[解决办法]
up
[解决办法]
用存储过程,安全,这样写很乱

[解决办法]
很不安全!回帖是种美德!
[解决办法]
学习。。
[解决办法]
1 DA BL UI 都混在一起,不方便代码维护,如果没有什么业务逻辑,那么至少也要将DA分离开。

2 这种写法看似简单,但一旦多有几个地方是同样功能,代码的总数反而会比分层的代码要多。

3 浪费性能,多个string拼接一般使用StringBuilder

4 不安全,SQL有可能被注入
[解决办法]
代码维护起来麻烦啊.
可读性也不好.
[解决办法]
群策群力
[解决办法]
不推荐这样写很大成分的原因是不安全sql注入

[解决办法]
效率问题
格式问题
可读性差
难以理解
[解决办法]
up
[解决办法]
没有看明白!

请指点
[解决办法]
感觉像是高空作业....很危险.
[解决办法]
非常不安全,很容易被注入!
[解决办法]
如果 GridView1.DataKeys[e.RowIndex].Value.ToString() 中的值是: ' or 1-1 --
这样的字符串, 数据库中的岂不是要被全改了.

读书人网 >C#

热点推荐