Strategy Pattern for Oracle Database?

I'm trying to implement the Strategy Pattern into my current code base. I would like to know if i'm going in the right direction on this?

IOracleDB.cs:

/// 
/// Strategy
/// 
interface IOracleDB
{
    DataSet DatabaseQuery(string query, OracleConnection oracleConnection);
    DataSet DatabaseQuery(string procedure, string parameters, OracleConnection oracleConnection);
}

OracleDBContext.cs:

```
///
/// Context
///
class OracleDBContext
{
private readonly string _EmailConnectionString = ConfigurationManager
.ConnectionStrings["EmailConnectionString"].ConnectionString;

private readonly string _PhConnectionString = ConfigurationManager
.ConnectionStrings["PhConnectionString"].ConnectionString;

private readonly IOracleDB _oracleDB;
private readonly OracleConnection _oracleConnection;

public OracleDBContext(IOracleDB oracleDB, string table)
{
_oracleDB = oracleDB;

switch (table.ToUpper())
{
case "Email":
_oracleConnection = new OracleConnection(_EmailConnectionString);
return;

case "Ph":
_oracleConnection = new OracleConnection(_PhConnectionString);
return;

default:
return;
}
}

public void ConnectToDatabase()
{
_oracleConnection.Open();
}

public void DisconnectFromDatabase()
{
_oracleConnection.Close();
_oracleConnection.Dispose();
}

public string ConnectionStatus()
{
if (_oracleConnection != null)
{
return _oracleConnection.State.ToString();
}
return "OracleConnection is null.";
}

public DataSet DatabaseQuery(string query)
{
return _oracleDB.DatabaseQuery(query, _oracleConnection);
}

public DataSet DatabaseQuery(string procedure, string parameters)
{
return _oracleDB.DatabaseQuery(procedure, parameters, _oracleConnectio

There are several issues that could be improved:

-
First of all, having concrete classes which are all tied to a specific database (in this case Oracle), is usually completely opposite of what a Data Layer's responsibility should be. Consider changing the classes' names as follows:

• OracleConnection --> DbConnection

• OracleCommand --> DbCommand

• OracleParameter --> DbParameter.

To instantiate a new command, don't use a specific constructor, but rather use the DbConnection.CreateCommand() method (and, likewise, DbCommand.CreateParameter() to create its parameters). That means you only need to change the actual connection instance, if you decide to switch from Oracle to a different db provider one day.

-
Next, strategy pattern is usually used to abstract a functionality which several different algorithms can execute, while exposing a single (common) interface. Creating a different strategy for different table queries is not appropriate, because the calling code already knows which table it is querying (there are no additional strategical choices your code can do).

-
I am not sure if the NotImplementedExceptions are thrown deliberately, or you really haven't yet implemented those methods. If you are throwing to indicate that a certain implementation doesn't support that functionality, that is another alarm that these two implementations are not really different strategies for the same task.

StackExchange Code Review Q#3187, answer score: 4