Attention: We are retiring the ASP.NET Community Blogs. Learn more >

ASP.NET DataProvider Singleton Vs. Static Vs. Instantiate When Needed

I have seen all versions used a hundred times.  Which is the best way in a closed shop ASP.NET application using strictly SQL Server for data storage?
 
Do you instantiate a singleton copy of the dataprovider for the entire application to use?  Or just a bunch of static methods (yuch)? Or do you instantiate the dataprovider every time needed?  Are there threading issues involved  here?  What about transactions?

2 Comments

  • Well, if you use the sqlhelper class instead of writing your own custom library I think that is the best way to go.

    When people quit, or if you bring on a contractor, they should be able to jump right in.



  • Why a singleton?? Only use singletons when you really need to. Possible examples are for queuing or synchronization. Singletons can cause concurrency/multithreading issues as well as performance bottlenecks.



    I would say instantiate when needed. ADO.net leverages connection pooling in order to minimize the creation of new connections. Just try to minimize the duration of database connections, so that the connection is made available again in the pool for the next database transaction.

Comments have been disabled for this content.