Click here to Skip to main content
12,999,157 members (41,165 online)
Click here to Skip to main content
Add your own
alternative version


40 bookmarked
Posted 5 Apr 2006

Data Access Component and the Factory Design Pattern

, 5 Apr 2006
Rate this:
Please Sign up or sign in to vote.
A generic Data Access Component implementation written in C# that supports SQL, Oracle, OLEDB and ODBC data providers. Using the Factory design pattern for instantiating the data provider correct and specific objects determined at run time.


Nearly every application today uses a relational database as its backend. Applications used to be monolithic and structured, but with the need for more functionality and ease of use, applications became larger, more complex and harder to maintain. The solution for rapid development became the clearer "Abstraction and Code Reuse."

Applications are layered:

  • Presentation Layer
  • Business Layer
  • Data Access Layer

A Data Access Layer usually provides the common mechanism and functionality for:

  • Opening and closing database Connections
  • Handling database Transactions
  • Executing SQL Commands, Data Readers and Data Sets

The Need for Change

Back in the old days, when I started development, I used to write a data access class specific for the data provider embedded in the application. Then I used to copy the class from one application into another.

These were the old days and the bad habits. I started to realize how bad it was when I needed to write a VB.NET application where I had to transform the C# data access class into VB.NET. I had to transform both classes from the SQL provider to the Oracle provider and then again to the OLEDB provider. Then things started to get really bad and messy: a lot of specific implementations sharing the same logic shattered across too many code files and classes.

Whenever I needed to add a new method, I had to write it down in too many places. Whenever I needed to fix one line of code, I had to fix it in too many code files. That's not to mention that I tend to forget, so I end up fixing the same bugs over and over again. Thus, "bad developer habits."

Realizing the Problem and Providing the Solution

Once I was talking to a friend of mine discussing the Factory Design Pattern and we ended the discussion with a practical Factory application, applying it to Data Access Components. We realized that if we needed to support two or more different data sources for the same application, then we would only need to change the connection string and not the Data Access Layer itself. By that time, I realized the need to program to interfaces instead of specific data providers’ implementations and that was my first real Object Oriented Programming lesson:

"Program to an interface and not to an implementation."

Another OOP approach:

"Favor object composition over inheritance."

Since that, the data access component common functionalities share the same logic, but differ in the native Connection, Command, Transaction and DataReader that each data source provider provides. Then it would be more practical and of more benefit to use an abstract class, providing the common logic in public methods, while providing abstract methods for each of the inherited data provider specific implementations to implement returning the native data source objects. Design guidelines:

"Use interfaces when you need classes that differ in implementation to have the same contract or protocol"

Included above source code for a generic Data Access Component implementation written in C# that supports SQL, Oracle, OLEDB and ODBC data providers, using the Factory design pattern for instantiating the specific data provider objects at run time based on the application configuration file or the caller defined data provider type. Somebody is doing his homework and changing the bad habits with the good ones.

Corrections? Suggestions? Comments? Feedback? Questions? Please e-mail me at



This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Waleed Al Tamimi
Web Developer
Egypt Egypt
No Biography provided

You may also be interested in...

Comments and Discussions

GeneralJust Drop by Pin
dienius27-Feb-12 23:10
memberdienius27-Feb-12 23:10 
GeneralGreat Stuff - Thanks for the effort Pin
cmprogrock11-Dec-06 15:46
membercmprogrock11-Dec-06 15:46 
Questionhow to check the implementation.. Pin
usafz26-Oct-06 6:33
memberusafz26-Oct-06 6:33 
Generalcongratulations! Pin
psychaos30-Sep-06 7:47
memberpsychaos30-Sep-06 7:47 
GeneralReally Good DataAccesLayer. One Note Pin
Ricardo Casquete13-Jun-06 23:46
memberRicardo Casquete13-Jun-06 23:46 
GeneralPLEASE finish the article! ! ! ! ! ! Pin
Brad Bruce6-Apr-06 3:01
memberBrad Bruce6-Apr-06 3:01 
GeneralRe: PLEASE finish the article! ! ! ! ! ! Pin
_alank6-Apr-06 7:04
member_alank6-Apr-06 7:04 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web02 | 2.8.170622.1 | Last Updated 5 Apr 2006
Article Copyright 2006 by Waleed Al Tamimi
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid