Collection object: Use CollectionBase, Generics, or DataSet

[_DS]

I need to create arrays of a custom data type (which is composed of
various strings, ints, the usual). The original was built using
CollectionBase. I was thinking about redesigning to use generics, but
I realized that DataSets may also work here.

I do need to display and edit lists of the items at various places.
In the previous version I used a custom ListView for most display
purposes.

Given that DataSets in VS2005 have so many extended features,
including integration with DataViews, etc., is there any reason not to
go this route? What are the disadvantages? Storage overhead? Access
speed?

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

"_DS" <_D*@Nospamforme.com> wrote in message
news:7t********************************@4ax.com...

I need to create arrays of a custom data type (which is composed of
various strings, ints, the usual). The original was built using
CollectionBase. I was thinking about redesigning to use generics, but
I realized that DataSets may also work here.
If it's working fine, I usually prefer do not change it
I do need to display and edit lists of the items at various places.
In the previous version I used a custom ListView for most display
purposes.
You can do this whatever route you go
Given that DataSets in VS2005 have so many extended features,
including integration with DataViews, etc., is there any reason not to
go this route? What are the disadvantages? Storage overhead? Access
speed?

The dataset would be the last option for me, you won't be using the most
useful features of it, like relationships, etc, it would also dilute the
concept of a type that (hopefuly) you have rignt now.

A generic collection works like a strong typed collection in most of the
cases, one of the motives to introduce genercs was to not have to implement
almost the same code each time you want a strong typed collection.

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

[Dale]

For what its worth, I agree with Ignacio. I wouldn't use DataSets either. I
refer to the DataSet as the Anti-OOP. Or perhaps I should call it the ~OOP.

Custom collections with indexers, and all the other cool features you get
from CollectionBase are definitely the way to go for framework version 1.1
and for the same reasons plus, as Ignacio said, better code re-use, generics
in framework version 2.0.

--
Dale Preston
MCAD C#
MCSE, MCDBA
"Ignacio Machin ( .NET/ C# MVP )" wrote:

Hi,

"_DS" <_D*@Nospamforme.com> wrote in message
news:7t********************************@4ax.com...

I need to create arrays of a custom data type (which is composed of
various strings, ints, the usual). The original was built using
CollectionBase. I was thinking about redesigning to use generics, but
I realized that DataSets may also work here.

If it's working fine, I usually prefer do not change it

I do need to display and edit lists of the items at various places.
In the previous version I used a custom ListView for most display
purposes.

You can do this whatever route you go

Given that DataSets in VS2005 have so many extended features,
including integration with DataViews, etc., is there any reason not to
go this route? What are the disadvantages? Storage overhead? Access
speed?

The dataset would be the last option for me, you won't be using the most
useful features of it, like relationships, etc, it would also dilute the
concept of a type that (hopefuly) you have rignt now.

A generic collection works like a strong typed collection in most of the
cases, one of the motives to introduce genercs was to not have to implement
almost the same code each time you want a strong typed collection.

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

[_DS]

On Fri, 27 Jan 2006 09:02:37 -0500, "Ignacio Machin \( .NET/ C# MVP
\)" <ignacio.machin AT dot.state.fl.us> wrote:

"_DS" <_D*@Nospamforme.com> wrote in message
news:7t********************************@4ax.com.. .

I need to create arrays of a custom data type (which is composed of
various strings, ints, the usual). The original was built using
CollectionBase. I was thinking about redesigning to use generics, but
I realized that DataSets may also work here.

If it's working fine, I usually prefer do not change it

Thanks for your reply, Ignacio. In this case it's not a matter of "If
it's not broke." The design is still in formative stages. I need to
settle on something that will endure.

I do need to display and edit lists of the items at various places.
In the previous version I used a custom ListView for most display
purposes.

You can do this whatever route you go

Yeah, I guess so. I was wondering if any subtleties in the DataSet
(vs Collection) would lend to advantages in binding or editing. If
there is no difference, then I guess the advantage goes to the
Collection approach. It should be faster and easier on ram.

[_DS]

On Sat, 28 Jan 2006 12:50:27 -0800, "Dale" <da******@nospam.nospam>
wrote:

For what its worth, I agree with Ignacio. I wouldn't use DataSets either. I
refer to the DataSet as the Anti-OOP. Or perhaps I should call it the ~OOP.
<g> Interesting comment, Dale. Are you excluding strongly typed
DataSets? (I'm guessing that you're referring to weak typing).
Custom collections with indexers, and all the other cool features you get
from CollectionBase are definitely the way to go for framework version 1.1
and for the same reasons plus, as Ignacio said, better code re-use, generics
in framework version 2.0.

I was initially thinking that there would be better binding features
with DataSets, but since I don't need relational capabilities I'll go
with CollectionBase for now. Generics later when I'm more comfortable
with them.