M
Massimo
I'm trying to build a DB-independent application using Visual Studio 2005
and the .NET Framework 2.0; I'm not using stored procedures, so I'd like the
application to not rely upon a specific DBMS.
I created a Factory class which instantiates DB-specific classes, and
returns them using IDbX interfaces:
public static IDbConnection CreateConnection();
public static IDbCommand CreateCommand();
public static IDbDataParameter CreateParameter(string name,DbType type);
The problem is with the last one; I pre-build commands to employ later,
using the following code:
---
IDbConnection connection = Factory.CreateConnection();
IDbCommand command = Factory.CreateCommand();
command.CommandText = "INSERT INTO Table VALUES (@Date,@Name,@Value)";
command.Parameters.Add(Factory.CreateParameter("Date",DbType.Date));
command.Parameters.Add(Factory.CreateParameter("Name",DbType.AnsiString));
command.Parameters.Add(Factory.CreateParameter("Value",DbType.Int32));
command.connection = connection;
---
Now, what I want to do is to be able to populate the parameters and run the
command when needed; but, when I recover the stored parameters, they're
returned as Objects instead of IDbDataParameters (or IDataParameters).
So, instead of writing code like
command.Parameters["Name"].Value = "john";
I need to use one of the the rather cumberstome casts:
(command.Parameters["Name"] as IDbDataParameter).Value = "John";
((IDbDataParameter) command.Parameters["Name"]).Value = "John";
I think this is really too much upcasting. Only something that implements
IDataParameter (including IDbDataParameter) can be placed in a
IDataParameterCollection, so why returning it as a plain Object instead of
using the the latest common interface?
If find this being really a nuisance. I'd like to know if there are design
reasons for this, of it was only a misdesign (which I hope can be fixed,
then).
Thanks
Massimo
and the .NET Framework 2.0; I'm not using stored procedures, so I'd like the
application to not rely upon a specific DBMS.
I created a Factory class which instantiates DB-specific classes, and
returns them using IDbX interfaces:
public static IDbConnection CreateConnection();
public static IDbCommand CreateCommand();
public static IDbDataParameter CreateParameter(string name,DbType type);
The problem is with the last one; I pre-build commands to employ later,
using the following code:
---
IDbConnection connection = Factory.CreateConnection();
IDbCommand command = Factory.CreateCommand();
command.CommandText = "INSERT INTO Table VALUES (@Date,@Name,@Value)";
command.Parameters.Add(Factory.CreateParameter("Date",DbType.Date));
command.Parameters.Add(Factory.CreateParameter("Name",DbType.AnsiString));
command.Parameters.Add(Factory.CreateParameter("Value",DbType.Int32));
command.connection = connection;
---
Now, what I want to do is to be able to populate the parameters and run the
command when needed; but, when I recover the stored parameters, they're
returned as Objects instead of IDbDataParameters (or IDataParameters).
So, instead of writing code like
command.Parameters["Name"].Value = "john";
I need to use one of the the rather cumberstome casts:
(command.Parameters["Name"] as IDbDataParameter).Value = "John";
((IDbDataParameter) command.Parameters["Name"]).Value = "John";
I think this is really too much upcasting. Only something that implements
IDataParameter (including IDbDataParameter) can be placed in a
IDataParameterCollection, so why returning it as a plain Object instead of
using the the latest common interface?
If find this being really a nuisance. I'd like to know if there are design
reasons for this, of it was only a misdesign (which I hope can be fixed,
then).
Thanks
Massimo