Last post Jul 02, 2007 02:10 PM by tarjoadi
Jul 01, 2007 05:19 PM|tarjoadi|LINK
Can anyone explain me the next thing:
protected IDataReader ExecuteReader(DbCommand cmd, CommandBehavior behavior)
cmd.ExecuteReader returns a DbDataReader object.
Why the ExecuteReader function 's returned type is the interface IDataReader? Shouldn't it be DbDataReader?
Jul 02, 2007 12:43 AM|MuteThis|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.
Jul 02, 2007 12:14 PM|tarjoadi|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
Jul 02, 2007 12:28 PM|sujitm|LINK
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.
Jul 02, 2007 02:10 PM|tarjoadi|LINK
Then, I suppose it's OK that instead of "DbCommand cmd" to be "IDbCommand cmd " ?