Data Provider independent code

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi,

I would like to have a data layer that is independent from the data provider
and ADO.NET. What I mean is that I would like to have a project that is
reusable in other projects, which use SQL Server, Sybase, or MySQL.

The goal is to avoid duplicating code as much as possible. For example, I
would like to have one "Fill" method which works for any data provider.

Is this possible at all? Any link to articles/code?

Thanks
Mike
 
Mike,

That should be OleDB look at the connections strings for that.

http://www.connectionstrings.com/

Altough it is of course not independent from ADONET, because that is an
integrated part of dotNet.

(You loose with this approach of you of course performance when it is Oracle
or SQLserver)

I hope this helps?

Cor
 
Mike said:
Hi,

I would like to have a data layer that is independent from the data
provider and ADO.NET. What I mean is that I would like to have a project
that is reusable in other projects, which use SQL Server, Sybase, or MySQL.

The goal is to avoid duplicating code as much as possible. For example, I
would like to have one "Fill" method which works for any data provider.

Is this possible at all? Any link to articles/code?
Click to expand...

this only works if you abstract away your SQL actions as well. If you don't
your code is never going to be independent of which database to use.

You can come a long way with interfaces, however not all actions are
implemented on the ADO.NET interfaces. One being savepoints in transactions
for example.

Frans.
 
¤
¤ Hi,
¤
¤ I would like to have a data layer that is independent from the data provider
¤ and ADO.NET. What I mean is that I would like to have a project that is
¤ reusable in other projects, which use SQL Server, Sybase, or MySQL.
¤
¤ The goal is to avoid duplicating code as much as possible. For example, I
¤ would like to have one "Fill" method which works for any data provider.
¤
¤ Is this possible at all? Any link to articles/code?

Unfortunately this probably isn't possible. The data access layer will have to be written to handle
different implementations amongst database products, such as the manipulation of BLOB data, data
type support, auto increment or sequencing, etc.

Your best bet would be to use stored procedures, which would be in line with what Frans is
suggesting, but the bottom line is that the data access layer will have to be database product
aware.


Paul ~~~ (e-mail address removed)
Microsoft MVP (Visual Basic)
 
Back
Top