Flexible Data Provider Architecture

  • Thread starter Thread starter Randall Howe
  • Start date Start date
R

Randall Howe

Hello,

I need advice on how to design flexible data handling for
an app that meets the following general installation
options:

1. data on local machine, single user, probably using
Access or FoxPro
2. data on network, multi-user, client server, SQL Server
or Oracle
3. data on web service using SQL Server and IIS

The option chosen must be transparent to the client.

Currently my design is based on separating the client app
from the data provider. The client instantiates a class
from a separate dll that handles communication between the client and the
data - currently SQL Server. I figured
that I would later expand data handling to other data
sources through subclassing. While I haven't since ruled
this out, I'm guessing that the web service version will
throw a wrench into this approach.

The question is how to provide elegant and transparent
switching between data handling code for a flexible and
growing list of data providers.

I'm tempted to implement an intermediate "generic" wrapper class containing
all the methods needed by the client. The wrapper class would then farm out
the actual work to provider-specific classes based on the provider in use.

Unfortunately, I have yet to work with web services, so
anything I come up with at this point would be a guess.

Any advice would be appreciated.

Randy
 
Hello,

I need advice on how to design flexible data handling for
an app that meets the following general installation
options:

1. data on local machine, single user, probably using
Access or FoxPro
2. data on network, multi-user, client server, SQL Server
or Oracle
3. data on web service using SQL Server and IIS

The option chosen must be transparent to the client.

Currently my design is based on separating the client app
from the data provider. The client instantiates a class
from a separate dll that handles communication between the client and the
data - currently SQL Server. I figured
that I would later expand data handling to other data
sources through subclassing. While I haven't since ruled
this out, I'm guessing that the web service version will
throw a wrench into this approach.

The question is how to provide elegant and transparent
switching between data handling code for a flexible and
growing list of data providers.

I'm tempted to implement an intermediate "generic" wrapper class containing
all the methods needed by the client. The wrapper class would then farm out
the actual work to provider-specific classes based on the provider in use.

Unfortunately, I have yet to work with web services, so
anything I come up with at this point would be a guess.

Any advice would be appreciated.

Randy
Click to expand...

In our shop we have successfully used the same application with MS SQL
Server, Oracle and MS Access by using the OleDb provider. The only
thing that changes when moving from one to the other is the connection
string. We do not have any provider specific code in the application,
but you must use data types that are common to all of the databases.
For example when using the archaic Oracle data base in this scenario
you must not use boolean data types because the main frame designers
at Oracle have no concept of boolean data. They prefer the
characters, 'Y' and 'N'. Also you cannot use the int type because
Oracle still uses the ancient main frame numeric data type for all
numeric values.

Otis
 
Back
Top