Question

Closed as exact duplicate of this question. But reopened, as the other Singleton questions are for general use and not use for DB access

I was thinking of making an internal data access class a Singleton but couldn’t convince myself on the choice mainly because the class has no state except for local variables in its methods.

What is the purpose of designing such classes to be Singletons after all?
Is it warranting sequential access to the database which is not convincing since most modern databases could handle concurrency well?
Is it the ability to use a single connection repeatedly which could be taken care of through connection pooling? Or Is it saving memory by running a single instance?

Please enlighten me on this one.

Answer 1

I’ve found that the singleton pattern is appropriate for a class that:

• Has no state
• Is full of basic ‘Service Members’
• Has to tightly control its resources.

An example of this would be a data access class.

You would have methods that take in parameters, and return say, a DataReader, but you don’t manipulate the state of the reader in the singleton, You just get it, and return it.

At the same time, you can take logic that could be spread among your project (for data access) and integrate it into a single class that manages its resources (database connections) properly, regardless of who is calling it.

All that said, Singleton was invented prior to the .NET concept of fully static classes, so I am on the fence on if you should go one way or or the other. In fact, that is an excellent question to ask.