Cast IDataAdapter

  • Thread starter Thread starter Bud James via DotNetMonster.com
  • Start date Start date
B

Bud James via DotNetMonster.com

if i have something like this

private IDataAdapter dA;

private class DBTalker(IDbConnection cn)
{
Type t=cn.GetType();
}

By getting the connection type i know then if it is sql, access, oracle

so it would seem that with that information i can cast dA as the
appropriate type. I know i could use an if statement but that seems like
overkill since i already have the type. any ideas??
 
Bud James via DotNetMonster.com said:
if i have something like this

private IDataAdapter dA;

private class DBTalker(IDbConnection cn)
{
Type t=cn.GetType();
}

By getting the connection type i know then if it is sql, access, oracle

so it would seem that with that information i can cast dA as the
appropriate type. I know i could use an if statement but that seems like
overkill since i already have the type. any ideas??
Click to expand...

You need to cast specifically to a compile-time known type, as
otherwise you're not adding any information to what the compiler knows.
Casting at runtime to the real type can't make any difference to what
is called or what methods you can call, because those are decided at
compile time.

Why do you particularly want to cast?
 
well let's say i have 35 classes

stores,
products,
customers,
employees etc...

that are collections of various datasets or something similar. now it
really doesn't matter to my classes what database i'm connecting to, well
that's not true there's an explicit call within each class to a
SqlDataAdapter or an object that calls a SqlDataAdapter which seems really
bad to me. So my thinking or lack there of is that i could have my
connection object ("a single line of code") determine what my type my
dataadapter and command object are.
 
Bud James via DotNetMonster.com said:
well let's say i have 35 classes

stores,
products,
customers,
employees etc...

that are collections of various datasets or something similar. now it
really doesn't matter to my classes what database i'm connecting to, well
that's not true there's an explicit call within each class to a
SqlDataAdapter or an object that calls a SqlDataAdapter which seems really
bad to me. So my thinking or lack there of is that i could have my
connection object ("a single line of code") determine what my type my
dataadapter and command object are.
Click to expand...

So what would you want, exactly? Suppose you *could* cast at runtime,
how would that affect your interface? What would you then change?
 
//Don't like this
public class Stores
{
public Stores()
{
System.Data.SqlClient.SqlDataAdapter dA=new SqlDataAdapter();
}
}


//Prefer something like this

public class Stores
{
public Stores()
{
DBTalker dBT = new DBTalker();
IDataAdapter dA=dBT.DA;
}
}

my original post didn't include a no parameter contructor but this should
give a more direct example of what i'm trying to get at. i really don't
want my 35 or 105 or 5 classes to have explicit information of "database
types"
 
my original post didn't include a no parameter contructor but this should
give a more direct example of what i'm trying to get at. i really don't
want my 35 or 105 or 5 classes to have explicit information of "database
types"
Click to expand...

So why do you need to be able to cast dynamically in order to achieve
that? You haven't shown what difference it would make to DBTalker.

I'd suggest just a set of "if" statements (either using the type you've
fetched, or as set of "is" comparisons). You may well need to create
the data adapter slightly differently for different providers anyway.
 
i guess i don't "need" to but it just appears to me that if the assembly
already knows that the connection is a SqlClient or OleDb then why should i
have to write an if statement... that's the way i've been doing it i just
figured there was a more generic way
 
Bud James via DotNetMonster.com said:
i guess i don't "need" to but it just appears to me that if the assembly
already knows that the connection is a SqlClient or OleDb then why should i
have to write an if statement... that's the way i've been doing it i just
figured there was a more generic way
Click to expand...

Nope, I'm afraid not.
 
Back
Top