Pros and Cons of using Singleton Pattern in DAL

Question

I have asked to use singleton pattern implemented DAL, but I think its difficult to pool the connections,use transactions..etc

I would like to know the pros and cons and

Answer 1

The singleton pattern is great for a DAL -- I use this in my own enterprise web application (hundreds of users and over 2,000 methods in 20-some singleton classes). The connection pooling is indeed handled best by ado.net and the sql server itself. If you are wanting to have multiple types of back-end server, that's not a problem. Even with a singleton pattern, you probably want a centralized data-access class that handles the specifics of actually making direct calls to the database (with parameters, text/procedure names, credentials/connection string all passed in).

In my situation, each method on a single corresponds 1:1 with a stored procedure in my database. This essentially makes a C# "front end" hook for each stored procedure, so that they can be called almost like native C# code, syntactically speaking. It makes calls to the DAL very straightforward. I have multiple singletons because of the massive number of SPs in question. Each SP has a prefix, like Development_, or Financial_, or Organization_ or whatever. Then I have a singleton class that corresponds to each, like Development, Financial, or Organization. So the sp Organization_ViewData would in C# be a method named ViewData on a singleton class named Organization.

That's just one way of doing it, of course, but I've found that to work very well with multiple developers and a large amount of code over the last six years. The main thing is that consistency is key. If a front-end programmer is looking at the name of a method on one of your singleton brokers, that should tell them exactly where it is going into the database end. That way if there's a problem, or if someone's having to search through code to try to understand it, there's less tracing that has to be done.