Design pattern to handle multiple databases via data access layer

c#-5.0data-access-layerdesign-patterns

I have been studying design pattern of "Gang of four design pattern".

I need to design data layer to handle multiple database as well as extend the function if required. The database could one is SQL, one XMl or some external system database.

What would be good design pattern to follow?

Edit:
Based on suggestion, i tried to implement DAO and Factory pattern in Data layer. To an extent i could get to the point.
But As per GOF desgin pattern, The data provider name decided which database object i can call.
Like below. Where as i am trying to make the layer dynamic so that multiple database can handled. If i follow below pattern then i can only access one database in one application.

If somebody has looked into Gang of Four Design pattern then Please guide me.

public class DaoFactories
{
    public static IDaoFactory GetFactory(string dataProvider)
    {
        // Return the requested DaoFactory
        switch (dataProvider)
        {
            case "ADO.NET.Access": return new AdoNet.Access.AccessDaoFactory();
            case "ADO.NET.Oracle": return new AdoNet.Oracle.OracleDaoFactory();

            case "ADO.NET.SqlExpress":
            case "ADO.NET.SqlServer": return new AdoNet.SqlServer.SqlServerDaoFactory();

            case "LinqToSql.SqlExpress": 
            case "LinqToSql.SqlServer": return new LinqToSql.Implementation.LinqDaoFactory();

            case "EntityFramework.SqlExpress": 
            case "EntityFramework.SqlServer": return new EntityFramework.Implementation.EntityDaoFactory();

            // Default: SqlExpress
            default: return new AdoNet.SqlServer.SqlServerDaoFactory(); 
        }
    }
}

Best Answer

You should look into the Repository Pattern and Data Access Object Pattern

Repository Pattern: In many applications, the business logic accesses data from data stores such as databases, SharePoint lists, or Web services. Directly accessing the data can result in the following: Duplicated code A higher potential for programming errors Weak typing of the business data Difficulty in centralizing data-related policies such as caching An inability to easily test the business logic in isolation from external dependencies

Data Access Object: In computer software, a data access object (DAO) is an object that provides an abstract interface to some type of database or other persistence mechanism. By mapping application calls to the persistence layer, DAO provide some specific data operations without exposing details of the database.

Related Solutions

The difference between Builder Design pattern and Factory Design pattern?

With design patterns, there usually is no "more advantageous" solution that works for all cases. It depends on what you need to implement.

From Wikipedia:

Builder focuses on constructing a complex object step by step. Abstract Factory emphasizes a family of product objects (either simple or complex). Builder returns the product as a final step, but as far as the Abstract Factory is concerned, the product gets returned immediately.

Builder often builds a Composite.

Often, designs start out using Factory Method (less complicated, more customizable, subclasses proliferate) and evolve toward Abstract Factory, Prototype, or Builder (more flexible, more complex) as the designer discovers where more flexibility is needed.

Sometimes creational patterns are complementary: Builder can use one of the other patterns to implement which components get built. Abstract Factory, Builder, and Prototype can use Singleton in their implementations.

Wikipedia entry for factory design pattern: http://en.wikipedia.org/wiki/Factory_method_pattern

Wikipedia entry for builder design pattern: http://en.wikipedia.org/wiki/Builder_pattern

C++ Singleton design pattern

In 2008 I provided a C++98 implementation of the Singleton design pattern that is lazy-evaluated, guaranteed-destruction, not-technically-thread-safe:
Can any one provide me a sample of Singleton in c++?

Here is an updated C++11 implementation of the Singleton design pattern that is lazy-evaluated, correctly-destroyed, and thread-safe.

class S
{
    public:
        static S& getInstance()
        {
            static S    instance; // Guaranteed to be destroyed.
                                  // Instantiated on first use.
            return instance;
        }
    private:
        S() {}                    // Constructor? (the {} brackets) are needed here.

        // C++ 03
        // ========
        // Don't forget to declare these two. You want to make sure they
        // are inaccessible(especially from outside), otherwise, you may accidentally get copies of
        // your singleton appearing.
        S(S const&);              // Don't Implement
        void operator=(S const&); // Don't implement

        // C++ 11
        // =======
        // We can use the better technique of deleting the methods
        // we don't want.
    public:
        S(S const&)               = delete;
        void operator=(S const&)  = delete;

        // Note: Scott Meyers mentions in his Effective Modern
        //       C++ book, that deleted functions should generally
        //       be public as it results in better error messages
        //       due to the compilers behavior to check accessibility
        //       before deleted status
};

See this article about when to use a singleton: (not often)
Singleton: How should it be used

See this two article about initialization order and how to cope:
Static variables initialisation order
Finding C++ static initialization order problems

See this article describing lifetimes:
What is the lifetime of a static variable in a C++ function?

See this article that discusses some threading implications to singletons:
Singleton instance declared as static variable of GetInstance method, is it thread-safe?

See this article that explains why double checked locking will not work on C++:
What are all the common undefined behaviours that a C++ programmer should know about?
Dr Dobbs: C++ and The Perils of Double-Checked Locking: Part I

Best Answer

Related Solutions

The difference between Builder Design pattern and Factory Design pattern?

C++ Singleton design pattern

Related Topic