G
Guest
I have recently create membership providers for several diferrent databases
which has led me down this path of thought.
I need to implement a data access layer for several different databases as
our users could be using any one of them. It seems to me that data access
code is not generic in that our stored procedures are all slightly different
to each other depending on the database used. Hence, I decided not you use
the data access blocks by MS.
So I am now in a position of having to write specific data access code
(faster) for all my databases. I thought that I could write a provider (as
in SqlMembership provide) for each of my databases and hence could plug /
unplug them in depending on the users requirements.
Apart from the extra code I need to write and the performance gains of using
specific data providers are there any other pros/cons that I should be aware
of in implementing my data access layer by implmenting ProviderBase. Is this
a good/bad idea.
Any input on this would be great.
Thanks.
which has led me down this path of thought.
I need to implement a data access layer for several different databases as
our users could be using any one of them. It seems to me that data access
code is not generic in that our stored procedures are all slightly different
to each other depending on the database used. Hence, I decided not you use
the data access blocks by MS.
So I am now in a position of having to write specific data access code
(faster) for all my databases. I thought that I could write a provider (as
in SqlMembership provide) for each of my databases and hence could plug /
unplug them in depending on the users requirements.
Apart from the extra code I need to write and the performance gains of using
specific data providers are there any other pros/cons that I should be aware
of in implementing my data access layer by implmenting ProviderBase. Is this
a good/bad idea.
Any input on this would be great.
Thanks.