This pattern is one of the best known patterns. This pattern allows only a single instance of itself to be created and gives access to this instance.

Usually you can create it this way:

    public class Singleton
    {
        private Singleton()
        {
        }

        private static Singleton instance = null;

        public static Singleton Instance
        {
            get
            {
                if (instance == null)
                {
                    instance = new Singleton();
                }

                return instance;
            }
        }

        public string SayHello()
        {
            return "Hello";
        }
    }

    public class test
    {
        public void Main()
        {
            Console.WriteLine(Singleton.Instance.SayHello());
        }
    }

But this is not thread safe. Because two threads could check the same if (instance == null) and create two instance of the Singleton class.

As a solution you can create Nested class and create instance of Singleton in it.

    public class Singleton
    {
        private Singleton()
        {
        }

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

        public string SayHello()
        {
            return "Hello";
        }

        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();
        }
    }

Normally when designing some parts of the application, one classes is always depends on the other classes. For example, business logic classes (BL) are depend on data access classes (DAL). This dependence can be in very different ways, for example, BL can call static methods of DAL, or create instance of DAL every time it needs it… But in this case it’s can be difficulties to test business logic with Unit tests because it’s difficult or even impossible to create mocks to the database. To solve this problem you can use Dependency injection pattern. Here is example of how I am using it. Firstly create our classes for DAL:

public class ProductDAL
    {
        public virtual List<Product> GetProducts()
        {
            // connect to DB and get products
            return new List<Product>();
        }
    }

And for BL:

public class ProductBL
    {
        private readonly ProductDAL dal;

        public ProductBL(ProductDAL dal)
        {
            this.dal = dal;
        }

        public List<Product> GetProducts()
        {
            // Get products, make some manipulation with the products,
            // e.g. sorting, filtering...
            return dal.GetProducts();
        }
    }

For parameter in constructor in BL I passed instance of DAL, it’s Constructor injection. And it’s very easy to test this calls with Rhino mocks.

[TestFixture]
    public class ProductBLTests
    {
        [Test]
        public void GetProductsTest()
        {
            MockRepository mocks = new MockRepository();
            ProductDAL dal = (ProductDAL)mocks.StrictMock(typeof(ProductDAL));
            using (mocks.Record())
            {
                List<Product> expectedProducts = new List<Product>();
                Product p = new Product();
                p.Name = "Dell Pc";
                p.Id = 333;
                expectedProducts.Add(p);

                Expect.Call(dal.GetProducts()).Return(expectedProducts);
            }

            using (mocks.Playback())
            {
                ProductBL bl = new ProductBL(dal);
                List<Product> products = bl.GetProducts();
                Assert.AreEqual(1, products.Count);
            }

        }
    }

Some developers can say than Dependency Injection is a not good pattern for database layer and there are some another patterns for this purpose, but I like this solution, and successfully using it.