Creating a Data Access class for multiple source types

I need to create a class that will accept a datasource type (MSSQL, Oracle, Access, Excel, ActiveDirectory, CSV file, Sharepoint etc.), the connection details for that type, and return a connection to that data source. After that I need to be able to interrogate the data source and return the available fields, and finally be able to extract data from any fields.

I was thinking that this sounds like a job for a interface, as the list of datasource types will grow over time, but I have never used interf开发者_Go百科aces.

Will this do?:

interface IConnectable
{
    void Connect();
}

class SourceMSSQL : RDB, IConnectable{}
class SourceOracle : RDB, IConnectable{}
class SourceAccess : RDB, IConnectable{}
class SourceExcel : RDB, IConnectable{}
class SourceCSVFile: FlatFile, IConnectable{}
class SourceSharePoint: FlatFile, IConnectable{}
class SourceActiveDirectory: FlatFile, IConnectable{}

also, how do I add Read() to that list?

PS: I only need to read, not write.

Yes, you are on the right track. An interface is a specification that allows you to work with an "unknown" class that gives you the service you want without you being tied to which service (in this case which database type) you are using.

In the code you have you would continue to build on you interface with something like:

interface IConnectable {
    IConnection Connect();
}

interface IConnection {
    IResultSet ExecuteQuery(string query);
}

and then implement these with concrete classes. In addition you need a factory to create whatever class you need:

class ConnectionFactory {
    IConnecable CreateConnection(...);
}

this so that you do not have to know which connection to create.

There are some help already present in the .NET framework. There is a class DbConnection with subclasses like SqlConnection that might help out. Also there are frameworks that help you wire up (create classes and associate them together) but that is a more advanced topic which may be something to try out later - begin with creating your own interfaces and implementation for those - that will be easier to understand.

Good thinking! Good luck!

P.S. In order to be able to easily reconfigure your software to create different objects implementing the same interfaces (which usually is a flexibility you want) you do not want to create objects using the constructors directly, instead have one central place where the objects are created. That place is usually referred to as a factory (it creates objects...). The factory can be very simple (maybe just look at a configuration string or a command line argument or whatever controls your behaviour), or more advanced where complex rules dictate which classes should be used in different situations.

There are frameworks that provides factories of different sorts for different situations, structuremap link is one and MEF (included in .NET 4 and is available at link) is another. But do not start with that, it will give you too much to think about at once - you can later on add that given that you are using interfaces to begin with!