开发者

asp.net sqldatasource vs doing it in code behind

开发者 https://www.devze.com 2023-03-18 20:53 出处:网络
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 a

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 respon开发者_如何学JAVAded. I appreciate your input.


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


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.

0

精彩评论

暂无评论...
验证码 换一张
取 消