Re: How to do non dependence on database vendor?

Tech-Archive recommends: Fix windows errors by optimizing your registry


"Brett" wrote...
> "Bjorn Abelli" wrote...

>> public ReflectionProxy(string assemblyName, string connectionClass,
>> string connectionString)
>> {
>> Assembly a = Assembly.Load( assemblyName );
>> Type t = a.GetType(connectionClass);
>> cn = (IDbConnection) Activator.CreateInstance(t, true);
>> cn.ConnectionString = connectionString;
>> cn.Open();
>> }


>> When I used it in my testprogram I have hardcoded the values, but these
>> can easily be put in some ini-file or something...
>>
>> In this case I simply connect to an Access DB, just to show how it can
>> work.
>>
>> -----------------------
>> IDbProxy proxy = new ReflectionProxy(
>> "System.Data, Version=1.0.5000.0, Culture=neutral, " +
>> "PublicKeyToken=b77a5c561934e089",
>> "System.Data.OleDb.OleDbConnection",
>> "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=mytest.mdb");
>> -----------------------

> I see. So you just pass in the connection parameters
> at runtime and get a connection? That's all it does?

Yes, that's about it. And that's all that is needed for the next layer,
where the SQL statements resides.

In this way you can use plain strings to tell what assembly to use, what the
class name for the Connection is, etc.

And it will work for most ADO.NET-drivers around... :-)

> Based on what you used in reflection, overloading would
> call the correct query version (for corresponding DB).
> Would that work?

In my example I used an OleDbConnection, but it works just as well with all
ADO.NET-drivers I know of, as all you really need for standard SQL compliant
DBs, is to expose the interface IDbConnection.

> I guess you would need multiple classes for this part
> but maintenance has signaficantly been reduced at this point.

Actually, you do *not* need multiple classes for this part, if you with
"this part" means the SQL-driven layer.

If you with "this part" also mean the non-SQL-DBs-layer, yes, then you would
also need classes on the higher abstraction layer, and the classes to
connect to those non-SQL-DBs

But as I believe I said already in my first post, that abstraction layer
might not even be interesting for you, if you think you can suffice with
only SQL-DBs. It was only a first thought on my behalf...

// Bjorn A



.