问题
This is probably going to boil down to a philosophical question more than anything, but is there really any major difference between using the <asp:sqldatasource> in the aspx file versus doing all of the work in the code behind?
If so what are they and why? I know I have my preferences, but I am just curious what others think.
Edit:
I purposely didn't put my preference in which is to put as much as possible in the code behind or even DAO. I was curious what others thought since I am going to have to update a bunch of code that has sqldatasource calls all over of the apsx files.
Thank you everyone who responded. I appreciate your input.
回答1:
Embedding your SQLDataSource within the asp.net page is coupling your presentation layer with your data access layer resulting in reduced testability and flexibility. I strongly suggest moving your data connections to their own classes and created a data access layer that your code behind pages could then draw from.
Ideally you'd seperate this even further into an N-Tier solution. Link
回答2:
For a simple application there isn't any reason not to use a asp:sqldatasource, but lots of developers want to separate the specifics of there data access strategy from the view logic.
What if you wanted to switch to an ORM like nHibernate? You would have to go rip out all the asp:sqldatasource from your aspx pages. If you did your wireing up in the code behind you wouldn't have to touch the aspx pages. If you abstracted even further, say into DAOs, you wouldn't even have to touch your code behinds, you could switch out your DAOs.
来源：https://stackoverflow.com/questions/6630291/asp-net-sqldatasource-vs-doing-it-in-code-behind