Class design to cater for different database in future

Asked Apr 24 '14 at 15:08

Active Apr 26 '14 at 22:40

Viewed 44 times

I'm implementing a database class to open connection, read, write, delete, update, etc. I'm currently using MySql server.

I'm attempting to write a database class that will be able to cater for different database in future. Maybe we will switch to SQL Server in future. because of this, I hope to design my class in such a way that I can write new classes for SQL Server and it wouldn't affect the client/controller that is calling the database class. I would like to stick to the design pattern principle, open for extension, closed for modification.

In strategy, I could create a abstract class, and create multiple concrete classes for MySql or SQL Server? Does anyone know which pattern should I follow that doesn't violate the rules for these patterns? I am not too sure about adapter. I read that adapter is used to interface existing classes. But in my case, I will be creating my new db classes for SQL Server. Unless I'm using an opensource class.

edited Apr 26 '14 at 22:40

Fuhrmanator

11,459
6
62
111

asked Apr 24 '14 at 15:08

chrizonline

4,779
17
62
102

What language are we looking at here? If it's java, I'd recommend using JPA instead of raw JDBC calls, as its database independant. – Johm Don Apr 24 '14 at 15:11
Hi Johm, im using PHP.. – chrizonline Apr 24 '14 at 15:11
Perhaps you might find http://www.php.net/manual/en/book.pdo.php or http://www.php.net/manual/en/book.dba.php useful? – Johm Don Apr 24 '14 at 15:14
You might want to look into hibernate or its alternatives: http://stackoverflow.com/questions/296587/light-weight-alternative-to-hibernate – Fuhrmanator Apr 26 '14 at 22:20

Class design to cater for different database in future

0 Answers0