> -----Original Message----- > From: Joel Mueller [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, April 30, 2002 6:24 PM > > I'm sure there is variation, but the architecture I described isolates > that variation from the rest of the application, while still allowing > one to code specifically for the database one is targeting. > For example, > one might support Oracle with OleDb at first, then switch to using the > native Oracle provider when it comes out of beta - the rest > of the code in the application doesn't have to know or care.
I see how your design isolates the use of one set of class from another but how does it isolate the syntax differences in the SQL strings used to parameterize the generalized objects returned. For Example: /// this is great since it is independent of RDBMS IDBConnection dbConnection = MyDBFactory.CreateConnection(); IDbCommand cmd = dbConnection.CreateCommand(); /// now the DBMS specifics start creeping in... cmd.CommandText = "Some RDBMS specific SQL statement" How do you NOT sprinkle RDMS specific SQL dialects in your code? Option 1: Store all the strings in some resource and swap in the version you need at runtime Option 2: Build the SQL string from a "PhraseBook" by mapping your version of SQL to your DBMS version of SQL. Option 3: Use stored Procs for cause the differences are fewer? Others? Thanks again, Jim You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
