Question

Possible Duplicate:
SqlConnection Singleton

This is the current code:

static SqlConnection CreateConnection() {
    SqlConnection conn = new SqlConnection(ConfigurationManager.ConnectionStrings["IMS"].ConnectionString);
    return conn;
}

Because the application will only ever need one open connection I’d like to move it into this design pattern. How do I translate the above into the below?

public sealed class Singleton
{
    private Singleton()
    {
    }

    public static Singleton Instance { get { return Nested.instance; } }

    private class Nested
    {
        // Explicit static constructor to tell C# compiler
        // not to mark type as beforefieldinit
        static Nested()
        {
        }

        internal static readonly Singleton instance = new Singleton();
    }
} 

I’ve just picked this pattern from Jon Skeet’s site – just went for the fully lazy version as it sounded like the best choice – might not be the correct one though.

Answer 1

There are very few situations were a singleton pattern is appropiated. You have to be sure that there is a mandatory need of one and only one instance of a class instance. Normally you don’t have this design requirement, but people tend to make it up.

Connections should be released as soon as you’re done with your unit of work. You should not keep a connection open forever so converting your connection to a singleton won’t help to improve your application design.

Connection pooling mechanism manage the complexity for you so you don’t have to worry about performance in relation to open and close connections since this is optimized by design.

Connecting to a database server typically consists of several time-consuming steps. A physical channel such as a socket or a named pipe must be established, the initial handshake with the server must occur, the connection string information must be parsed, the connection must be authenticated by the server, checks must be run for enlisting in the current transaction, and so on.

In practice, most applications use only one or a few different configurations for connections. This means that during application execution, many identical connections will be repeatedly opened and closed. To minimize the cost of opening connections, ADO.NET uses an optimization technique called connection pooling.

Connection pooling reduces the number of times that new connections must be opened. The pooler maintains ownership of the physical connection. It manages connections by keeping alive a set of active connections for each given connection configuration. Whenever a user calls Open on a connection, the pooler looks for an available connection in the pool. If a pooled connection is available, it returns it to the caller instead of opening a new connection. When the application calls Close on the connection, the pooler returns it to the pooled set of active connections instead of closing it. Once the connection is returned to the pool, it is ready to be reused on the next Open call.

Source MSDN