Click here to Skip to main content
11,716,249 members (87,097 online)
Click here to Skip to main content

Versatile and Extendible Data Access Factory

, 17 Jul 2004 35.1K 440 27
Rate this:
Please Sign up or sign in to vote.
Using and extending the data access classes, and runtime selection and instantiation using a factory and XML configuration file.

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

Share

About the Author

G Ryno
Web Developer
United States United States
No Biography provided

You may also be interested in...

Comments and Discussions

 
GeneralNomenclature Pin
chibaken12-May-05 0:41
memberchibaken12-May-05 0:41 
GeneralTackles the easy problems Pin
Steven Campbell19-Jul-04 3:23
memberSteven Campbell19-Jul-04 3:23 
GeneralRe: Tackles the easy problems Pin
G Ryno19-Jul-04 11:37
memberG 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   

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

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