We have an abstract base class for the data access layer, which has a static Create method that determines which concrete subclass to return based on the database type specified in a configuration file. Each concrete subclass talks to a particular database type as natively as possible, using stored procedures and the appropriate *Connection objects and such. In the business layer, we can just do something like CustomersDB.Create() to get back the appropriate database-specific subclass, without having to know what that subclass is.
> -----Original Message----- > From: dotnet discussion [mailto:[EMAIL PROTECTED]] > On Behalf Of Murphy, James > Sent: Tuesday, April 30, 2002 2:18 PM > To: [EMAIL PROTECTED] > Subject: [DOTNET] How are you supporting multiple DB vendors? > > > I'm curious what folks are using to abstract the underlying > DBMS from your .NET apps. I know lots of shops that just > pick a RDBMS and run with it - and have simpler designs - > that would be nice. But lets say you need to support both > ORACLE and SQL Server? > > You can program to the ADO.NET interfaces so instead of > SqlConnection or OleDdConnection use IDbConnection or use > OleDdConnection always and sacrifice performance. But what > about the actual SQL statements? How do you virtualize the > variants? String tables in resource only assemblies? Do you > put everything in stored procs and simplify the SQL embedded > in your code? Or Don't use stored procs because you have SQL > statement generation code a la RogueWave's DBTools. > > I'd love to hear all strategies big and small. > > Thanks > Jim > > You can read messages from the DOTNET archive, unsubscribe > from DOTNET, or subscribe to other DevelopMentor lists at > http://discuss.develop.com. > > You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
