I am porting some old ASP.NET code to .NET 4.5. I am used to using SqlConnection/SqlCommand/SqlDataReader the old fashioned way. Now I am looking at using async primitives in hopes of better performance.
Here is my old code for opening a connection:
static DBWrapper Open(string connKey) {
string connStr = WebConfigurationManager.ConnectionStrings[connKey].ConnectionString;
SqlConnection c = new SqlConnection(connStr);
c.Open();
DBWrapper retVal = new DBWrapper();
retVal._c = c;
return retVal;
}
Class DBWrapper is just a thin wrapper over SqlConnection that has some extra methods I need.
Here is how I converted to the new async style:
static async Task<DBWrapper> Open(string connKey) {
string connStr = WebConfigurationManager.ConnectionStrings[connKey].ConnectionString;
SqlConnection c = new SqlConnection(connStr);
var v = c.OpenAsync();
DBWrapper retVal = new DBWrapper();
await v;
retVal._c = c;
return retVal;
}
Basically, while the connection is being opened, I am able to create a new DBWrapper object concurrently.
What I am confused is if this function really performs better or worse. The overhead of task creation and waiting on it may be much more than the time it takes to create a new DBWrapper object. Whether or not I use async, I am ultimately returning a fully built connection object anyway.
Here is a method that returns the list of users from the database:
List<MyUsers> getUsers() {
using(SqlCommand cmd ...) {
using(SqlDataReader reader ...) {
while(reader.Read() {
... Fill the list
}
}
}
I can convert this method as well into async style as well:
while (await reader.ReadAsync())
... Fill the list
}
Once again I don't see any performance gains. In fact, in the second example, I don't even do anything else concurrently while waiting on ReadAsync().
Is this the correct approach or is there a better way to use async paradigm with database connections and queries?