Click here to Skip to main content
Click here to Skip to main content

Versatile and Extendible Data Access Factory

By , 17 Jul 2004
 

Introduction

This document describes how to use the Data Access Factory to create run-time objects that connect to and query Oracle or SQL Server. The demo project shows how the data provider can be changed without changing any code at all. The factory class is capable of creating any type of object you specify, as long as it inherits from the abstract class DataAccessBase. The factory gets its instructions on what type of object to create from an XML file specified by the developer and which is generally located in the project bin directory (for Window Forms projects) or in a virtual directory (for Web Applications). Currently, the application contains two derived classes of the DataAccessBase class: OracleDAO and SQLServerDAO. The assembly can easily be modified to include additional data providers such as Microsoft Access.

The core Data Access Factory is implemented along with classes for data access (DAO classes) in an assembly called DAL (Data Access Library). (The DAO classes mentioned should not be confused with earlier VB 6 nomenclature referencing RecordSet and other objects. They are un-related.) The demo project is available in a zip file by following the above link. The sample shows how to use the factory from a console application – use the demo to quickly learn how to use the factory.

The Data Access Factory assembly is useful for developers who want to code business logic or presentation logic without being concerned about what database vendor will be used. Without this type of logic, business logic code and presentation logic code are very difficult to de-couple from the objects used to access databases.

Additionally, clients of the Data Access Factory assembly can use multiple data sources.

Background

I looked at the article Data Access and Transaction Handling Framework as a resource to use instead of what I developed, but decided not to use it because it used SQL statements as well as database object instantiation instructions all contained in the configuration file. I did not want that. Additionally, I wanted my database object instantiation to be setup differently than in that article. However, the current project is implemented as a factory, as is the project in the referenced article. If interested, you may want to consider evaluating that code as an alternative to using this code.

Using the code

The code block below shows how the sample application uses the DataAccessFactory and DataAccess classes.

//Define (declare and set memory aside) a factory object 
// that takes care of creating and returning
// a reference to the correct data access object type.

DataAccessFactory myDBFactory = new DataAccessFactory();

//Declare a variable capable of being any DAO object type
DataAccessBase myDBObj;

//Define a object (locally defined) that will help
// with the dirty chores of setting properties of
// the factory.  This object is not necessary, but just
// helps abstract out unnecessary details used in this
// particular test.
try 
{
    factoryProperties = new factoryHelper();

    myDBFactory.ObjectTypeToCreate = factoryProperties.getDaoObjectType;
    myDBFactory.ObjectSetupIndex = factoryProperties.getIndex;
    myDBFactory.ConfigFileName = factoryProperties.getXMLFileName;
}
catch (Exception e)
{
    Console.WriteLine ("Problem in Factory Helper");
    Console.WriteLine ("Message: " + e.Message);
    Console.WriteLine ("Source: " + e.Source);
    return;
} 

try
{
    //Use the factory to instantiate the appropriate type of
    // DAO object.  Assign the object to the base class object.

    myDBObj = myDBFactory.CreateVendorDAO();

    //Use the DAO object to generate a return a dataset based on
    // a user supplied query.
    string strSQL = "select * from customers";
    DataSet resultsDS = myDBObj.getDataSet(strSQL);
}
catch (Exception e)
{
    //Catch and report any problems.
    Console.WriteLine ("Found prblem.");
    Console.WriteLine("Error message: [{0}]", e.Message);
    Console.WriteLine("Source [{0}]", e.Source);
}

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here

About the Author

G Ryno
Web Developer
United States United States
Member
No Biography provided

Sign Up to vote   Poor Excellent
Add a reason or comment to your vote: x
Votes of 3 or less require a comment

Comments and Discussions

 
You must Sign In to use this message board.
Search this forum  
    Spacing  Noise  Layout  Per page   
GeneralNomenclaturememberchibaken12 May '05 - 0:41 
Nothing fundamentally wrong with your code, but I have a comment to make about your use of DAO as the name of certain methods in your project - you may be aware that DAO was the precursor to Microsoft's current ADO data access infrastrucutre (back in the days of VS6). When I initially read your piece I thought you had written an old legacy DAO tool. As I said, not a biggy but if you go on to promote stuff like this...
GeneralTackles the easy problemsmemberSteven Campbell19 Jul '04 - 3:23 
I guess the article must be more about the Factory style of getting a data access object, so this may be offtopic, but I'll say it anyway...
 
Any generic data access interface needs to address the following:
 
* A way to manage the differences in database provider syntaxes (e.g. SQL Client provider expects a different type of parameter placeholder than OleDb Client provider).
* A way to manage differences in SQL syntax between different database platforms.
 
Unless it does those 2 things, it has very limited value. You may as well just use OleDb and call it a day.
 

my blog
GeneralRe: Tackles the easy problemsmemberG Ryno19 Jul '04 - 11:37 
Steven
 
Thanks for your input.
 
I really did have two purposes to writing the application: one was to get familiar with using a factory to create run-time determined objects, and another was to have versatile data access – even if the data access could not handle anything but standard SQL. Additionally, I wanted to post it to Code Project to gain experience of having peer review and to gain experience of writing articles – I need both.
 
I agree that to be more useful, the application would have to managing differences in SQL syntax between database platforms. I think that the subset of SQL that does not change across platforms can be handled as it is now. I am thinking that the remaining portions of SQL can be handled using stored procedures. I know this would place the burden on the clients using the factory. Do you feel this is a reasonable approach?
 
Also, Steven, I believe the differences in database vendors is handled adequately by having the factory class read configuration information based upon the subclass it is creating. The configuration information is gathered and placed into a hash table and passed to the subclass’s initialization method. The number and name of initialization parameters is dependant upon the database vender. See the configuration file example below.
 
Gary
 



UIConnection
Data source for UI
<ObjectType>SQLServerDAO, DAL</ObjectType>
1


OracleUI
Data source for UI
<ObjectType>OracleDAO, DAL</ObjectType>
1


<ObjectType>SQLServer</ObjectType>
1
(local)
Northwind
yes


<ObjectType>Oracle</ObjectType>
1
MyOracleID
Password
InstanceName


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

Permalink | Advertise | Privacy | Mobile
Web01 | 2.6.130523.1 | Last Updated 18 Jul 2004
Article Copyright 2004 by G Ryno
Everything else Copyright © CodeProject, 1999-2013
Terms of Use
Layout: fixed | fluid