The quick answer is that returning the interface instead of an implementation is more flexible/portable/refactorable. I believe DbDataReader is provider independant and that is probably the type underneath the IDataReader that is returned by ExecuteReader.
Remeber, you cannot instantiate an interface, so there is an underlying type that is being referenced. It probably wouldn't take much to figure out what the underlying type is, but I don't have VS.Net on this laptop and a quick google was fruitless.
Ben
MCAD .Net (70-315, 70-320 & 70-229)
:One that throws dirt loses ground:
Yes.....DbDataReader implements IDataReader, which is dependent by data providers that access relational databases. Also, ExecuteReader returns a DbDataReader object.
I understand why we use an interface in a factory method that has a interface return type, but I don't understand this case when we know that ExecuteReader always returns a DbDataReader object. How is it more flexible/portable/refactorable ? Maybe you
can give me an example
ADO.Net has certain interfaces and base classes which each implementor of ADO.Net provider has to implement/derive. E.g. SQL Server ADO.Net provider implements this interface. ADO.Net then uses the generic interfaces defined by it to interact with the providers
of various databases. In essence, ADO.Net is programmed against these interfaces and not any specific classes / providers.
- Sujit
Dont forget to click "Mark as Answer" on the post that helped you.
This credits that member, earns you a point and marks your thread as Resolved so we will all know you have been helped.
tarjoadi
Member
27 Points
93 Posts
returned type
Jul 01, 2007 04:19 PM|LINK
Hi,
Can anyone explain me the next thing:
protected IDataReader ExecuteReader(DbCommand cmd, CommandBehavior behavior) { return cmd.ExecuteReader(behavior); }
cmd.ExecuteReader returns a DbDataReader object.
Why the ExecuteReader function 's returned type is the interface IDataReader? Shouldn't it be DbDataReader?
Adrian
MuteThis
Participant
1126 Points
209 Posts
Re: returned type
Jul 01, 2007 11:43 PM|LINK
The quick answer is that returning the interface instead of an implementation is more flexible/portable/refactorable. I believe DbDataReader is provider independant and that is probably the type underneath the IDataReader that is returned by ExecuteReader. Remeber, you cannot instantiate an interface, so there is an underlying type that is being referenced. It probably wouldn't take much to figure out what the underlying type is, but I don't have VS.Net on this laptop and a quick google was fruitless.
MCAD .Net (70-315, 70-320 & 70-229)
:One that throws dirt loses ground:
tarjoadi
Member
27 Points
93 Posts
Re: returned type
Jul 02, 2007 11:14 AM|LINK
Yes.....DbDataReader implements IDataReader, which is dependent by data providers that access relational databases. Also, ExecuteReader returns a DbDataReader object.
I understand why we use an interface in a factory method that has a interface return type, but I don't understand this case when we know that ExecuteReader always returns a DbDataReader object. How is it more flexible/portable/refactorable ? Maybe you can give me an example
10x
sujitm
Contributor
3153 Points
518 Posts
Re: returned type
Jul 02, 2007 11:28 AM|LINK
Hi,
ADO.Net has certain interfaces and base classes which each implementor of ADO.Net provider has to implement/derive. E.g. SQL Server ADO.Net provider implements this interface. ADO.Net then uses the generic interfaces defined by it to interact with the providers of various databases. In essence, ADO.Net is programmed against these interfaces and not any specific classes / providers.
Dont forget to click "Mark as Answer" on the post that helped you.
This credits that member, earns you a point and marks your thread as Resolved so we will all know you have been helped.
tarjoadi
Member
27 Points
93 Posts
Re: returned type
Jul 02, 2007 01:10 PM|LINK
Then, I suppose it's OK that instead of "DbCommand cmd" to be "IDbCommand cmd " ?