Data Provider independent code

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
 
C

Cor Ligthert

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
 
F

Frans Bouma [C# MVP]

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?

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.
 
P

Paul Clement

¤
¤ 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)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top