Best way to implement classes with list of classes that can have a list of other classes
BobRoyAce
called MerchantOwnerList. This property is a List(Of MerchantOwner),
where MerchantOwner is another class. So, Merchants can have zero or
more MerchantOwners. Now, MerchantOwner also has a property, called
AttachedDocumentList, which is a List(Of AttachedDocument), where
AttachedDocument is yet another class.
I have a form that the user can use to add a new Merchant. That form
has a private variable, called _oMerchant, that I use to store entered
information. I don't save anything out to the DB until the user is
finished and I make sure that all is well with the Merchant.
On this form, the user can click on a button to add a new
MerchantOwner. This brings up another form which, in turn, allows the
user to add new AttachedDocuments to the MerchantOwner. When the user
confirms the new MerchantOwner, and after I make sure that all is well
with it, I go back to the Merchant form and add the newly added
MerchantOwner to the Merchant's MerchantOwnerList. Mind you, all of
this is being done in memory and nothing is being saved to the DB.
Everything is saved only after the user clicks the Save button.
So, to recap, I may have classes like follows:
Public Class Merchant
Private _oMerchantOwnerList as List(Of MerchantOwner)
...
End Class
Public Class MerchantOwner
Private _AttachedDocumentList as List(Of AttachedDocument)
...
End Class
Public Class AttachedDocument
...
End Class
Is doing data entry this way (i.e. storing all this data in the
objects, and lists of objects) the best way to do this? Or, is there
some better "pattern" out there for how to accomplish this?
Just FYI, one of the issues with doing things this way is that, until
I save the record out to the DB, I don't have a MerchantID, for
example. As a result, when I create MerchantOwners, I can't assign the
foreign key to MerchantID until later, after I save the Merchant
record and get back the assigned MerchantID. MerchantID is an
autoincrementing field in my SQL Server 2005 table. Perhaps this
doesn't mean the way I'm doing the form data stuff (i.e. in memory) is
wrong, but that I should reconsider using the autoincrementing fields.
If I instead used a function to get the next MerchantID to use, I
could assign that to the foreign key fields. Then, if I don't end up
saving anything after all, I just don't end up using that MerchantID.
RobinS
One says use business objects to do all of your data work and display in the
UI, pushing the changes down into the database as needed (or retrieving data
as needed).
One says use strongly typed datasets. I think for complicated applications,
this is not great, because if you have to change one, you have to change the
tableadapter too, and regenerate the dataset IIRC.
One says using datasets and read/write from a database as needed.
I'm a fan of business objects (check out "Doing Objects in VB2005" by
Deborah Kurata -- great book), so *I* think the way you are doing it is
fine. Just update your parent and get the ID# before saving the updates to
the children. I would do this and let the database handle it, rather than
keeping track of it myself. You could always force them to save the Merchant
before letting them add the children records, and this would give you the ID
that you need.
HTH,
RobinS.
-----------------------------
"BobRoyAce" <br...@omegasoftwareinc.com> wrote in message
news:3f33f89f-34f8-45a2...@e25g2000prg.googlegroups.com...
BobRoyAce
> this is not great, because if you have to change one, you have to change the
> tableadapter too, and regenerate the dataset IIRC.
Yea, that can be a pain in the neck, to be sure. I suppose there's a
performance gain in some scenarios though.
> I'm a fan of business objects (check out "Doing Objects in VB2005" by
> Deborah Kurata -- great book)
I'll check out that book...thanks. I think it's time for me to learn a
bit more about business objects.
> , so *I* think thewayyou are doing it is
> fine. Just update your parent and get the ID# before saving the updates to
> the children. I would do this and let the database handle it, rather than
> keeping track of it myself.
Yea, that makes sense. This is what I'm going to do.
> You could always force them to save the Merchant
> before letting them add the children records, and this would give you the ID
> that you need.
My problem is that I have a business rule that is enforced whereby a
Merchant MUST have at least one MerchantOwner. So, I won't allow
saving the Merchant until that business rule is met.
RobinS
Well, you could add it, and then if they don't add a MerchantOwner, remove
it. OTW you'll just have to wait until they add at least one MerchantOwner
before adding the Merchant.
What if they delete all of the MerchantOwners? Then what happens? You'll
have to handle that if you have a business rule saying no Merchants w/o
MerchantOwners.
Good luck,
RobinS.