Why aren't there any interfaces??

I'm working with DataSets in my code and cannot find a suitable Interface to
reference.

As a work-around, I've written an Interface (IDataSet) that defines all of
the public method signatures of a DataSet class. A custom class (DataSetExt)
implements that Interface and delegates public method calls to *base*.

I know that in taking this approach I've left myself open to a slew of
potential problems especially if the signatures of the DataSet class change.
However, the System.Data.DataSet class has no primary interface....????

Any thoughts on this?

thx

Marina
Tue Jan 06 17:00:26 CST 2004

Why do you need dataset to implement an interface? You can inherit it if
you want, and you can get polymorphism that way.

"cg" <me@tryitnexttime.net> wrote in message
news:%23V47CYK1DHA.2636@TK2MSFTNGP09.phx.gbl...
> I'm working with DataSets in my code and cannot find a suitable Interface
to
> reference.
>
> As a work-around, I've written an Interface (IDataSet) that defines all of
> the public method signatures of a DataSet class. A custom class
(DataSetExt)
> implements that Interface and delegates public method calls to *base*.
>
> I know that in taking this approach I've left myself open to a slew of
> potential problems especially if the signatures of the DataSet class
change.
> However, the System.Data.DataSet class has no primary interface....????
>
> Any thoughts on this?
>
> thx
>
>
>

William
Tue Jan 06 21:54:31 CST 2004

CG:

What benefit are you looking for? I make no pretense on being the Pattern
know it all, but what would such an interface solve? I'm not arguing
against your claim, but implementing IDBConnection makes perfect sense, as
does IDBCommand. But what would you do with IDataSet? There's no
ISqlDataSet or IOleDbDataSet that would do anything different from DataSet
and since DataSets are as decoupled as it gets, what common properties would
such a thing share across the board? I ask this from purely an intellectual
POV, I simple don't know, but that doesn't mean I think you are wrong - I
just don't understand the objective?

I've seen for instance Rocky Lhotka's version of a DataReader which handles
Null values. Clever and Brilliant. But DataReaders are coupled to a
Database so the same 'null' problem that Oracle programmers deal with
confronts Sql Server Programmers. Could the same be said of a DataSet
though? Yes, you could claim that the null thing confronts everyone because
of NullReferenceExceptions. However, a subclass would solve this wouldn't
it? And is Rocky's method contrary to this? I don't think so, I think it's
totally consistent. Anyway, I'm babbling, and am probably wrong, but I'd
like to see why.

Bill
"cg" <me@tryitnexttime.net> wrote in message
news:%23V47CYK1DHA.2636@TK2MSFTNGP09.phx.gbl...
> I'm working with DataSets in my code and cannot find a suitable Interface
to
> reference.
>
> As a work-around, I've written an Interface (IDataSet) that defines all of
> the public method signatures of a DataSet class. A custom class
(DataSetExt)
> implements that Interface and delegates public method calls to *base*.
>
> I know that in taking this approach I've left myself open to a slew of
> potential problems especially if the signatures of the DataSet class
change.
> However, the System.Data.DataSet class has no primary interface....????
>
> Any thoughts on this?
>
> thx
>
>
>

cg
Thu Jan 08 08:45:37 CST 2004

Thank you for the comments.

What I'm attempting to implement is a 'DataAccess' class that handles the
execution of Oracle Stored Procedures. The result of the method calls are
datasets that can be bound to such controls as a DataGrid or any control
that implements IListSource. I already have an implementation where
IListSource is returned from the methods in my prototype DataAccess class.
This however, requires casts on the calling side of the code that can be
avoided with the use of an Interface that exposes the methods of the DataSet
class. Using IListSource works, but it is not what I want to do.

As far as patterns go, this concept leans more towards an Adapter. My
implementation of DataSetExt extends System.Data.DataSet and implements the
IDataSet interface. Each method in the DataSetExt class delegates to the
*base* class (i.e. System.Data.DataSet). This, to me, is the implementation
that suits my needs. Essentially, I have a DataSet class that now has an
Interface that supports Polymorphic behavior and enables my DataAccess class
to return a proper Interface that exposes the methods of the
System.Data.DataSet class. This totally removes the necessity of casts on
the calling side of the code.

CG
"cg" <me@tryitnexttime.net> wrote in message
news:%23V47CYK1DHA.2636@TK2MSFTNGP09.phx.gbl...
> I'm working with DataSets in my code and cannot find a suitable Interface
to
> reference.
>
> As a work-around, I've written an Interface (IDataSet) that defines all of
> the public method signatures of a DataSet class. A custom class
(DataSetExt)
> implements that Interface and delegates public method calls to *base*.
>
> I know that in taking this approach I've left myself open to a slew of
> potential problems especially if the signatures of the DataSet class
change.
> However, the System.Data.DataSet class has no primary interface....????
>
> Any thoughts on this?
>
> thx
>
>
>

cg
Thu Jan 08 10:10:55 CST 2004

One point I forgot to mention is that in defining an explicit Interface to
for use with my DataAccess class is to adhere to OOP fundamentals. The
general rule is to NEVER return a type of an Implementation class (e.g.
DataSet or subclass of DataSet), but an Interface type. I've used this
technique for as long as I can remember especially with Java (cringe) ;)

CG

"cg" <me@tryitnexttime.net> wrote in message
news:%23V47CYK1DHA.2636@TK2MSFTNGP09.phx.gbl...
> I'm working with DataSets in my code and cannot find a suitable Interface
to
> reference.
>
> As a work-around, I've written an Interface (IDataSet) that defines all of
> the public method signatures of a DataSet class. A custom class
(DataSetExt)
> implements that Interface and delegates public method calls to *base*.
>
> I know that in taking this approach I've left myself open to a slew of
> potential problems especially if the signatures of the DataSet class
change.
> However, the System.Data.DataSet class has no primary interface....????
>
> Any thoughts on this?
>
> thx
>
>
>