Is using the singleton pattern a good idea when accessing libraries using MVC?

Question

I have a web app, this app as you already know will have a lot of requests, and each request will run on a different thread, meaning that if I use singleton to access my DAL library it will not be a problem.

However I'm unsure about wether this is the best approach, because I read that one request my use different threads sometimes, and I have also read that locking threads may cause a performance lost sometimes when using single instances.

Just so you understand me better this is what I plan to do:

DAL <- SingleInstance <- BAL <- SingleInstance <- Controllers <- Views

Is this a good approach?

This is the singleton I plan to use:

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

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

       internal static readonly Products instance = new Products();

Note: My Dal will access the database using ADO.NET(I have my reasons to use ado), and the BAL will only use this method to do select or CRUD operations.

My Ado.NET code:

public static readonly string ConnectionString = @"Server=localhost;Database=test;Uid=root;Pwd=test;";

    public bool IsProduct(string name)
    {
        var conn = new SqlConnection(ConnectionString);
        bool result;
        try 
        {
            conn.Open();
            var command = new SqlCommand();
            SqlParameter[] parameters = new SqlParameter[1];
            parameters[0] = new SqlParameter("@Product", name);
            command.Connection = conn;
            command.CommandText = "SPC_GET_PRODUCT";
            command.CommandType = System.Data.CommandType.StoredProcedure;
            result = Convert.ToBoolean(command.ExecuteScalar());
        }
        finally 
        {
            conn.Close();
            conn.Dispose();
        }
        return result;
    }

Thanks.

Answer 1

In general, it's probably not a good idea, for a couple reasons:

• Singleton's are really hard to use with multiple threads for anything complex. It's unlikely most of the libraries you'll be calling into (like Entity Framework) are thread-safe, so you'll need to do a ton of locking to protect resources.

• You'll almost certainly suffer performance-wise waiting for locks, as opposed to just creating new instances of your service layer. There's no point to having a fully asynchronous platform if everyone is waiting for a single database context.

• They are difficult to unit test

• It is semantically incorrect. Singleton's mean's there's just one instance of the class. It doesn't make sense that you'd only have one instance of your business logic running at some time.

Singleton's have their place for simple things, like accessing configuration data, or when creating an instance is really expensive. But in almost all other cases, there's a better way to do it.

There are other answers that explain all the problems with Singleton's.