Why use a CollectionBase class here vs dataset or dataview?

  • Thread starter Thread starter jc
  • Start date Start date
J

jc

RE: Why use a CollectionBase class here vs dataset or dataview?

I'm looking at some vb.net 2005 code that was generated from a
homegrown Codesmith Template that generate all of the retreival and
update code for typical vb.net / asp.net data maintenance
applications. For some reason they have two class files for each
table, one is a collection class. Oddly both have the same properties
for each table column duplicated.. a lot of duplicate code and I'm
trying to understand why. Also, I'm trying to explain why the use of a
collection class anyways.

Perhaps the motivation was a more pure OOP approach, or perhaps
eventual scalability.



1. why the two classes?

Imports System.Configuration.ConfigurationManager
Namespace WH
Public Class Collaborator
Private m_ColId As Integer
Private m_Lastname As String
Get
Return m_ColId
End Get
Set(ByVal value As Integer)
m_ColId = value
End Set
End Property

and the other like this:

Namespace WH
Public Class colCollaborator
Inherits System.Collections.CollectionBase
#Region "List Data Structure"
Public Structure s_Collaborator
Private m_Result As String
Public Property ColId() As Integer
Get
Return m_ColId
End Get
Set(ByVal value As Integer)
m_ColId = value
End Set
End Property


Can't they be combined?

2. Sorry for the potentially noob OOP question, but why even use a
collection class? Any way to have a class that stores a dataset or a
dataview? And if not and a valid reason for the collection class, why
not one class file and one set of properties? The collection class
uses a reader to load the collection list..

Me.List.Add(FromDataReader(oRdr, blnAdd0Index))

Thanks for any help or information!
 
jc,

One of the basics of OOP are the enumerable collections.

Look at this more simpliefied schema
Collection A holds a reference to another collection B which has a
Collection of
C. C is a simple item that only holds a back reference to B where it is in.
As you fill one C in table B you see in the debuger in quickwatch something
like this.

A
.B
C
B
C
B
etc. and that goes endless on, I did not try to show
this exact because as I see this in quickwatch I too have always to follow
the lines.

This is probably the reason that some people think that a dataset is a very
memory consuming thing, while it is only something as I tried to explain
above. In this sample there is only one item that holds a reference back to
B and is in that B collection, which is again referenced by A in a
collection.

A dataset is something that holds references to
-collections of relations which has a reference back to the dataset
-collections of tables which has a reference back to the dataset
-some name giving properties
-the collection of tables holds references to
-collections of columnames which have a reference back to the table
-collections of rows which have a reference back to the table
-some properties including the dataview which
has a reference back to the datatable
-the rows holds references to items which are in
fact the true object which holds the data.

In my idea it is because of that people don't understand this that they have
made all kind of solutiong so make by them so called lightweight
datacollection. In fact those are probably mostly consuming much more
resources.

Cor
 
Back
Top