1

Suppose I have one abstract class e.g. DatabaseConnection with 3 ABSTRACT methods Openconnection , Executequery, closeconnection.
This DatabaseConnection class is inherited by different classes to make connection with mysql , oracle, sql server... So how is the structure of inherited clasess?
and what is the best way to create the instance of derived class which increase the maintainability and reusability of code?

Himanshu
  • 4,327
  • 16
  • 31
  • 39
  • I'm not sure I entirely understand the question, but answered with how to set up an abstract class. Let me know if you want more info! – BradleyDotNET May 23 '14 at 04:40

3 Answers3

3

If you have an abstract class:

public abstract class DatabaseConnection
{
   public DatabaseConnection(...) // Optional if you want a base constructor
                                     with or without required parameters.
   public abstract void OpenConnection();
   ...
}

Then an implementation just has to override everything:

public class SQLServerDatabaseConnection : DatabaseConnection
{
   public SQLServerDatabaseConnection(...) //Whatever params you want
   //Or public SQLServerDatabaseConnection(...) : base (...) //if base has required params
   {
   }

   public override void OpenConnection()
   {
   }

   ...//Overrides for every other pure virtual method
}
BradleyDotNET
  • 60,462
  • 10
  • 96
  • 117
1

Firstly create an interface for the class. A class implementing an interface is far easier to replace when it is referenced by it's interface, than it is when it has been referenced directly everywhere in your code. Interfaces help make your code more maintainable.

Secondly, use an injection framework to create instances of your database class.

e.g with NInject.. At one point in your app bind the interface to the desired implementation...

Bind<IDatabaseConnection>.To<MySqlConnection>();

to create an instance somewhere in your app...

// Creates an instance of the class bound 
IDatabaseConnection connection = _kernel.Get<IDatabaseConnection>(); 
Mick
  • 6,527
  • 4
  • 52
  • 67
  • I'm not going to downvote, but I would think twice before saying there is no good use case for an abstract class. He may well have one, though DBConnection does sound more likely to be an interface. – BradleyDotNET May 23 '14 at 04:49
  • I never said he shouldn't have a baseclass. You can choose to implement an interface anyway you like, that's the whole point of using an interface. The question is about maintainability and structure. How the innards of one class is implemented doesn't really relate to that, but don't worry I'm not going to down vote ;) – Mick May 23 '14 at 06:19
1

What you are trying to implement is quite similar to the data provider model that has already been implemented in ADO.NET. You have an abstraction layer available in the System.Data.Common namespace in the form of DbCommand, DbDataAdapter, DbDataReader etc. Your data access layer (DAL) can then be written in a data provider-agnostic manner, meaning you are using factories to intantiate the actual data provider types that implement the generic/abstract classes and/or interfaces. In ADO, the factories know which provider to instantiate using the dataProvider attribute of the provided connection string. http://www.devx.com/dotnet/Article/27297

  • I'd go further and say using LINQ/Entity Framework or NHibernate. Going by the category of the question which is oop/design, I didn't take the question literally, it might just be an example and a general question about oop. – Mick May 23 '14 at 06:17