codequest
asked on
DB Server Connection Management with ADO.NET Connected Data Access
I am rewriting a 2006-era ASP.net application. To maintain high platform migrate-ability, one option that I am looking at is ADO.NET connected data access as described here:
http://msdn.microsoft.com/en-us/data/ff707264.aspx#_Toc261428884
Given that starting assumption, I am looking for additional information on how to manage server resources and connections in this approach.
Any guidance on this would be appreciated.
Thanks!
http://msdn.microsoft.com/en-us/data/ff707264.aspx#_Toc261428884
Given that starting assumption, I am looking for additional information on how to manage server resources and connections in this approach.
Any guidance on this would be appreciated.
Thanks!
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
What version of Visual Studio .NET do you have?
What type of web site are you planning (MVC, Web Forms, OWIN/Katana, ...)?
Do you know about Entity Framework?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks for the inputs. I'm using VS2013, MVC, and I know about EF.
The option I need to work out is "ADO.NET connected data access", the first option in the article.
The reason I'm going to work through this option first is that I want to maintain the lowest level of abstraction for both performance and migrate-ability.
While I appreciate the tip on the "dispose" method, I need to look at some contextual material on this to understand things like how many connections I'm going to have open, the cost of leaving connections open, the cost of opening and closing connections, etc.
I appreciate that EF resolves many of these questions, however, that's a different path that I won't pursue until I've more completely understood what it takes to manage ADO.NET connected data access.
The option I need to work out is "ADO.NET connected data access", the first option in the article.
The reason I'm going to work through this option first is that I want to maintain the lowest level of abstraction for both performance and migrate-ability.
While I appreciate the tip on the "dispose" method, I need to look at some contextual material on this to understand things like how many connections I'm going to have open, the cost of leaving connections open, the cost of opening and closing connections, etc.
I appreciate that EF resolves many of these questions, however, that's a different path that I won't pursue until I've more completely understood what it takes to manage ADO.NET connected data access.
ASKER
http://forums.asp.net/t/932515.aspx
Apparently best practice for ASP net SQL connections is to open and close them frequently, and the rule is open late close early.
That's kind of what I was looking for; in essence you don't manage connections you just open them use them and close them.
Unless someone disagrees I'm going to go with that answer thanks.
Apparently best practice for ASP net SQL connections is to open and close them frequently, and the rule is open late close early.
That's kind of what I was looking for; in essence you don't manage connections you just open them use them and close them.
Unless someone disagrees I'm going to go with that answer thanks.
ASKER
I've requested that this question be closed as follows:
Accepted answer: 0 points for codequest's comment #a39811181
for the following reason:
most accurate
Accepted answer: 0 points for codequest's comment #a39811181
for the following reason:
most accurate
I guess that is what I have also stating.
"To manage resources in both above options, invoke dispose method on datacontext object to release the resources."
"To manage resources in both above options, invoke dispose method on datacontext object to release the resources."
ASKER
I'll award points based on apeter's comment.
ASKER