When programming in ASP.NET, you can get very quick, effective functionality out of using DataBound controls (GridView, FormView, etc) with an SQLDataSource control on the page (In my opinion, anyway - I could be alone on that one). For instance, I often use these types of controls to create basic search functionality - like looking at Order History in a Shopping Cart application.

However, this answer on SO got me thinking: Is the use of the SQLDataSource control considered bad practice? I've not been able to find any resources online that substantiate this claim, so I thought I'd ask here.

The question on SO is regards calculating the grand total of a column in a GridView. The downsides of the SQLDataSource pointed out by the answerer (in their comment) include:

  • ASPX is presentation, not business logic.
  • This practice causes you to repeat SQL on every page that needs it.
  • When you make a change to a DB you have to change SQL in aspx.
  • Because it makes simple tasks like displaying grand total hard.
  • Solution provided calculates grand total it in DataBound event. What if you don't use control with DataBound event?
  • Because it's not testable.

I'm somewhat new to ASP.NET development (coming from a Java / C# background), and I just wanted to make sure I'm not heading down the wrong path here (with using the SQLDataSource control).

  • 3
    I faced those doubts myself when I was starting with ASP.NET development a few years ago. There will be a point where you will eventually discover that the SQLDataSource has its limitations, and that in more complex scenarios you will be forced to rely on codebehind for your databinding. Also, once you get the hang of databinding from the codebehind, you won't want to go back to SQLDataSource in your aspx pages. Oct 20, 2011 at 16:00

2 Answers 2


If you're just learning, sure use SqlDataSource. The main drawback is the fact it doesn't let you encapsulate anything; your logic is directly on the page and directly tied to the control(s). Even databinding directly is a bad practice nowadays (the DataSource property should call a service or repository or gateway or something external to the UI that returns a collection), but it's fine for a newbie who's learning the ropes. Just understand the limitations and remember that you probably won't use that way of doing things for any major project.

  • Thanks for the answer! Could you elaborate on the statement "Even databinding directly is a bad practice nowadays"? Are you saying a better was is to use a service/gateway to fill out a DataSet (or something like it), set the DataSource to that, then call DataBind()? Oct 20, 2011 at 18:59
  • The accepted best practice is to have a service/gateway/repository/etc (some kind of data layer is the point) that returns a list of objects, e.g. an IList<Customer>, set that to the DataSource and then DataBind(), as opposed to making direct SQL calls or similar (although again that's fine when learning). Oct 20, 2011 at 19:23
  • Thanks Wayne M. I tried this out on one of my smaller projects last night (swapping the SQLDataSource out in favor of code-behind DataBinding) - it really is a whole lot more flexible. Oct 21, 2011 at 12:43

There are a couple of considerations. First of all, the technology allows for this so why not use it? Well there may be many reasons but one I can think of is from the system architecture and security perspective. Is your webserver allowed to have a direct connection to your (back end?) database? If so it is perfectly ok to use databound controls, if not You'll have to create an intermediate transport mechanism (ans hence the SqlDataSource is out of scope).

Triggering business rules might be an other. Still many databases are used to enforce business rules, if so it's all good. If you have to trigger diffrent code to enforce your business rules things might get complicated and using SqlDataSource could be considered bad practice.

The testing argument, I don't really see that as problematic, one might have to write a different view to be able to assert the outcome but that is not neccesarily problematic.

However writing SQL code and business logic in aspx pages is a problem and should be isolated in a reusable library.

  • "the technology allows for this so why not use it?" - I'm glad I'm not the only one that thought that. Definitely some good things to think about in your answer, thanks! Oct 20, 2011 at 19:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.