Question

I have a class containing methods to fill DropDowns, return DataSet, return Scalar or simply excute a query. In one of my older posts in StackOverflow, I submitted a buggy code of the same class. Based on the advice of the contributors, I have improved the code and want to know whether this class is suitable to be used in a high-concurrent environment:

public sealed class reuse
{
    public void FillDropDownList(string Query, DropDownList DropDownName)
    {
        using (TransactionScope transactionScope = new TransactionScope())
        {
            using (SqlConnection con = new SqlConnection(ConfigurationManager.ConnectionStrings["MyDbConnection"].ConnectionString.ToString()))
            {
                SqlDataReader dr;
                try
                {
                    if (DropDownName.Items.Count > 0)
                        DropDownName.Items.Clear();

                    SqlCommand cmd = new SqlCommand(Query, con);
                    dr = cmd.ExecuteReader();

                    while (dr.Read())
                        DropDownName.Items.Add(dr[0].ToString());

                    dr.Close();
                }
                catch (Exception ex)
                {
                    CustomErrorHandler.GetScript(HttpContext.Current.Response,ex.Message.ToString());
                }
            }
        }
    }
}

I want to know whether to dispose Command and DataReader objects as well or they too will get automatically disposed with USING?

Answer 1

The the command/reader: they would be disposed by “using”, but only if you use “using” for them, which you should.

Criticisms:

• you are mixing UI and data access horribly – the exception handling in particular gives no indication to the calling code (although personally I’d keep the control code separate too), and assumes the caller always wants that script-based approach (to me, if this code fails, things are very wrong: let that exception bubble upwards!)
• no mechanism for proper parameters; my suspicion then, is that you’re concatenating strings to make a query – potential (but very real) risk of SQL injection
• you mention high-concurrent; if so, I would expect to see some cache involvement here
• for code maintenance reasons, I’d move all “create a connection” code to a central point – “DRY” etc; I wouldn’t expect an individual method like this to concern itself with details like where the connection-string comes from

Frankly I’d just use dapper here, and avoid all these issues:

using(var connection = Config.OpenConnection()) {
     return connection.Query<string>(tsql, args).ToString();
}

(and let the caller iterate over the list, or use AddRange, or data-binding, whatever)