a class that cointains a collection of related objects..

  • Thread starter Thread starter Brad Pears
  • Start date Start date
B

Brad Pears

I have a physical DB that includes two tables in a one to many relationship.
When designing the business classes for this, I have a class for each of
these tables - but I want the main class to include as one of it's
properties the collection of the related classes (i.e. the child rows from
table 2)

1) Does this make sense to do this?
2) Would I simply define a "collection" property to accomodate this " i.e.
"dim cDetailItems as collection"
3) When the business object is instantiated, that's where I would then call
methods to fill the collection correct?
4) Do I need to do anything different in the collection properties "get" and
"set" code?

Is there anything else I should be doing or thinking of?

Thanks, Brad
 
Hi Brad,

I am not clear what you want to accomplish with your collection. What
is it a collection of?

You mention about a DB. Is it a server DB (sql server)? Or is it an
Access DB? In either case, you also mention tables. So I am just
guessing that you want to retrieve data from these tables. What do you
want to do with this data? It sounds like you want to put this data
into a collection object. What is the purpose of this? Do you want to
display this data? Will this data be used for calculating something and
you will display that?

If you could share this information, I could suggest some ideas.

Rich
 
Hi Rich... I should have been a little more specific for sure... I just want
to be sure I am on teh right track - that is all...

Yes, the DB I am referring to is a back end SQL Server 2000 database. I
call SQL stored procedures (not embedded SQL) from my vb.net 2005
application to access and load data to/from these tables.

Basically I am trying to develop a business class that encompasses these two
tables. I am very new to OO design so pls bear with me. I have a parent
table and a related child table in a one-many relationship. When I
instantiate the business object, depending on parameters supplied in the
"new()" clause, I beleive I will want to call a method(s) on that object
that will then go out and get me the related rows from the child table, and
load them into my collection so I can then display the collection items in a
listview control etc...

Now, I could create multiple business objects but that does not make
sense -- that is typically where the data objects will come in - as I would
have one data object for each table. In my business object I want to
represent just this one "thing" (object) which is a "Post". Since one single
"Post" can have multiple associated "Details", I think (and hope) I am on
the right track by designing the business object so that I can retrieve the
details using say a "GetPostDetails" method. This method would then fill the
collection property on the Post object. Once filled, I can then do whatever
I want with the collection - display it, print it, etc... etc...

Does this make sense? Do you think I am on the right track?

Thanks, Brad
 
I think I am following you now, and is pretty much what I thought you
were looking for.

Well, if you are new to OO design, not to worry. The days of having to
create little classes for stuff sort of came and went (at least for
VB2005) for data storing/displaying. I create a custom class for stuff
like printing. As for collection objects, I haven't used one for a few
years now. I store data in datasets/datatables which can be available
as much as you want - depending on how much scope you give your dataset.
Ex:

----------------------------------------------
Imports System
Imports System.Data.SqlClient

Public Class Form1
Dim da as SqlDataAdapter, ds As DataSet
Dim conn as SqlConnection
Private Sub Fomr1_Load(...)Handles...
conn = New SqlConnection
conn..ConnectionString = "Data Source=yourSvr;Initial
Catalog=yourDB;Integrated Security=True"
ds = New Dataset
da = New SqlDataAdapter
da.SelectCommand = New SqlCommand
da.SelectCommand.Connection = conn
da.SelectCommand.CommandType=CommandType.StoredProcedure
da.SelectCommand.CommandText = "yourSP"
da.Fill(ds,"tblSteve") '--tblSteve gets created on the fly
'--now populate a datagridview control on your form
datagridview1.Datasource = ds.Tables("tblSteve")
End Sub
----------------------------------------------

In this sample I made the dataset at the Form level. So
ds.Tables("tblSteve") will be alive as long as Form1 is alive. And
tblSteve will contain whatever rows/columns your SP contains/returns.
And these can be automatically displayed in a datagridview control (much
easier to deal with and way more flexible than a Listview control).

Well, this is my suggestion.

HTH

Rich
 
Brad Pears said:
I have a physical DB that includes two tables in a one to many
relationship. When designing the business classes for this, I have a class
for each of these tables - but I want the main class to include as one of
it's properties the collection of the related classes (i.e. the child rows
from table 2)

1) Does this make sense to do this?
2) Would I simply define a "collection" property to accomodate this " i.e.
"dim cDetailItems as collection"
3) When the business object is instantiated, that's where I would then
call methods to fill the collection correct?
4) Do I need to do anything different in the collection properties "get"
and "set" code?

Is there anything else I should be doing or thinking of?

Thanks, Brad
Click to expand...

If you are always going to want the list of children when you access the
parent, then go ahead and put a List(of Children) in the parent class. When
your parent class is instantiated, you can either set the list to a blank
list (just instantiate it), or go get hte data (which is what I would do).

So for example, if your parent class was Customers and the children were
Orders, you would have a Customer Class and an Order class.

You could also set up an OrderList class and use that in the Customer class
instead of instantiating the list there. Then the OrderList class
constructor could take a CustomerID and load the list.

You can set the OrderList to just be a property in the Customer class.

Does that help?

By the way, check out "Doing Objects in VB2005" by Deborah Kurata. It's a
great book about using business objects and illustrates this sort of thing
beautifully.

RobinS.
GoldMail, Inc.
 
Great... Thanks for your help... I have not used a datagridview control at
all... Do you have some sample code you could forward that would populate a
datagridview control based on that sample you provided? At this point I am
not going to be allowing the user to add/delete/update rows directly from
the control - it would be for viewing only - but that may change once I see
it in action...

Thanks, Brad
 
Back
Top