tags:

views:

47

answers:

3

Is this a good practice and is there anything I need to look out for? I was binding repeater to an asp:SqlDataSource. Primary reason for doing this is to gain more control of the SqlCommand (e.g. CommandTimeout).

Example:

    try
    {
        SqlDataReader MyReader = GetSomeResultsFromSqlCommand();
        MyRepeater.DataSource = MyReader;
        MyRepeater.DataBind();
    }
    catch (Exception ex)
    {
        throw ex;
    }
    finally
    {
        MyReader.Close();
    }
+2  A: 

Your code seems to be OK as written and does not necessarily appear to violate any best practices. You could however redactor the code a bit and utilize the "using" statement instead of the try, catch, finally...


I personally try to avoid using the SqlDataSource as it tightly couples your front end code to your data. To keep separation of concerns, I'd create a function within a class that can get this data for you and can be customized as much as needed.

RSolberg
+7  A: 

This is a perfectly fine thing to do - let me offer a more succinct syntax that will provide the same results and offer the same fail-safe cleanup abilities:

using (SqlDataReader MyReader = GetSomeResultsFromSqlCommand())
{
    MyRepeater.DataSource = MyReader;
    MyRepeater.DataBind();
}
Andrew Hare
+1  A: 

Nothing really wrong with that if you wrap it in a using block as Andrew suggests. The one other thing I might do is use an ObjectDataSource instead and return an IEnumerable of some strongly typed business object. This will push you towards using good business and data tiered code, make it easier to use an ORM if you want, and give you the extra control over you sql commands that you desire.

Joel Coehoorn
+1 Good suggestion.
Andrew Hare
Haven't done this yet. Would you provide link to good how-to example if available? Thanks.
Eddie