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
DataBoundevent. What if you don't use control withDataBoundevent? - 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).
Best Answer
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 (theDataSourceproperty 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.