SQLConnection用Using语句,从里面调用SQLDataReader吗?
只是想确保这是调用连接并从数据库中获取数据的最佳方式,或者我应该如何在 using 语句之外调用 datareader? (为了更快地关闭连接?)或者您个人对此有何更改?
using (SqlConnection cn = new SqlConnection(connStr))
{
using (SqlCommand cm = new SqlCommand(connStr, cn))
{
cm.CommandType = CommandType.StoredProcedure;
cm.CommandText = "GetExchRatesByDate";
cm.Parameters.Add("@Date", SqlDbType.VarChar).Value = txtStartDate.Text;
cn.Open();
SqlDataReader dr = cm.ExecuteReader();
while (dr.Read())
{
firstName = (string)dr["GivenName"];
lastName = (string)dr["sn"];;
}
dr.Close();
}
}
Just want to make sure this is the best way to call a connection, and grabbing data from a database, or should I some how call the datareader outside of the using statement? (in order to have the connection close quicker?) or is there anything you would personal change to this?
using (SqlConnection cn = new SqlConnection(connStr))
{
using (SqlCommand cm = new SqlCommand(connStr, cn))
{
cm.CommandType = CommandType.StoredProcedure;
cm.CommandText = "GetExchRatesByDate";
cm.Parameters.Add("@Date", SqlDbType.VarChar).Value = txtStartDate.Text;
cn.Open();
SqlDataReader dr = cm.ExecuteReader();
while (dr.Read())
{
firstName = (string)dr["GivenName"];
lastName = (string)dr["sn"];;
}
dr.Close();
}
}
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
您无法在 using 语句之外成功调用 datareader,因为它需要打开的连接来读取数据。
连接将以您所拥有的方式足够快地关闭,甚至不会真正“关闭”。它将返回到连接池(假设您正在使用一个)。由于您可能是这样,因此您无需担心在此上下文中连接关闭的速度有多快,因为需要连接的应用程序的其他部分将从池中获取可用的连接。假设您没有真正高流量的应用程序,在这种情况下它可能会变得很重要,但是有很多很多并发用户,您可以通过增加池中的连接数来缓解这个问题。
Chris 也提出了一个很好的观点:它应该在 using 语句中:
在这种情况下,如果你的阅读器抛出异常,它永远不会到达
dr.Close();
所以它会保持打开状态的时间比需要的时间长得多(甚至可能在应用程序的生命周期内)。数据读取器
You can't successfully call the datareader outside of the using statement as it requires an open connection to read the data.
The connection will close fast enough the way you have it, and doesn't even really "close". It will be returned to the connection pool (assuming you are using one). Since you probably are, you don't need to worry about how fast the connection closes in this context as other parts of the application needing a connection will grab an available one from the pool. This is assuming that you don't have a really high traffic application, it could become important in that scenario, but that is many, many, many concurrent users, and you can alleviate that issue, with upping the number of connections in the pool.
Chris brought up a good point too: It should be in a using statement:
In this instance, if your reader throws an exception, it won't ever get to
dr.Close();
so it will be left open a lot longer than it needs to be (Maybe even for the life of the application).Data Reader
您不仅无法在
using
语句之外调用SqlDataReader
,因为变量中声明的所有内容都将被释放,而且您需要一个打开的连接来读取数据,您最好编写一个将返回的对象,甚至是您的对象的列表。Not only you cannot make a call to the
SqlDataReader
outside of theusing
statement as all declared within variables will be disposed, and you need an opened connection to read the data, you had better write an object that will be returned, or even a list of your object.datareader 实现了 IDisposable,因此它也应该包含在 using 子句中。其他一切看起来都不错。
The datareader implements IDisposable so it should also be wrapped in a using clause. Everything else looks good.
其他人已经介绍了它,但我喜欢使用的另一件事是 AddWithValue:
可以写为:
Others have covered it but one more thing that I like to use is AddWithValue:
could be written as:
我会考虑将 SQLConnection 放入工厂方法中。 (如果它被称为负载)
另外,我不会在 dr.Read 周围有一个 while 循环
你只期待一个答案,那么当没有结果或有很多结果时会发生什么???
不太确定我是否喜欢选角,但可能还可以。
我认为您围绕此代码进行了单元测试,并传入了连接字符串等...(显然工厂的想法会使单元测试变得更加困难,所以也许不值得做...)
您的 using 语句对我来说看起来很好。
I would consider putting the SQLConnection into a factory method. (if it's called loads)
Also I would not have a while loop around the dr.Read
You are only expecting one answer, so what happens when there are no results or many results????
Not too sure if I like the casting, but probably OK.
I amsume that you have unit tests around this code with the connectionstring being passed in etc... (obviously the factory idea would make unit testing harder, so perhaps not worth doing...)
Your using statements look fine to me.