Persisting form data with one to many relationship

[Diane Yocom]

I'm still very new to ASP.Net, so wanted to get some advice on how to solve
the following design problem (sorry my explanation is so long):

I'm developing an ASP.Net intranet app (using VB.Net for my business
objects) that will allow my users (max of about 25) to enter information
about families and their children. On one page, I need to collect general
information about the family (such as address and phone number) and specific
information (such as name, birthdate, and much more) about one or many
children. Once ALL information is entered about the family and all
children, I'll save it all to the database (into a Family and Child table,
with Family ID being a foreign key in the Child table)

In order to allow for an unlimited number of children, I had planned to
collect the family information on the main page and display a list of any
existing children. The user could choose to edit information about one of
those existing children, or choose to add a new child. In order to add or
edit a child, I'd display a popup window with all the needed child
information.

I've done this many times in the past (using ASP Classic), but in those
cases, I always had the parent record already saved in the database before I
tried to add any children to it (e.g., the Family record was in the database
before any Children were added), so I could just have the Child popup window
save itself to the database as long as I knew the Family ID.

In this project, however, I want to save it all at once, so I need to
persist any data entered in the Children pages, along with everything
entered in the Family page. I was thinking the best thing to do would be to
just store my Family business object (with its collection of Child objects)
in the Session object, then I can update the appropriate Child object each
time the Child popup window is opened and save the entire object to the
database once the user is done.

I know in ASP Classic, however, it was not a good idea to store VB objects
in the Session. Is this true for VB.Net objects? Are there any pitfalls to
this approach that I should be aware of? Are there better design
alternatives for me to pursue?

Thanks in advance,
Diane

[Rich]

First, Session management is supposed to be much improved in .NET. In larger applications, you can actually deploy separate server(s) that are dedicated to Session state storage. I've never done this, but evidently there's also a way to use SQL Server as a back-end to your session state servers

But enough of that - with only 25 users, you won't need to get that fancy - unless of course other applications running on the same server platform as your app are much larger and you have serious capacity issues

My approach would be this: As users are entering the data you're talking about, keep the data in Data Table objects. The Data Tables will all be members of a single Data Set - and you can persist this Data Set with a single Session variable. The column structure of each Data Table will match one of your actual database tables - the data set becomes sort of a mini-database of its own

You can even add data relation objects into your Data Set - for managing one-to-many relationships - and, primary keys, foreign keys, validation criteria, and all sorts of things that can help keep the data valid and correct in terms of integrity rules, etc.

When a complete set of parent/child records are ready to be permantly stored in the database, you'll execute a set of commands - via OLEDB (or SQL) DataAdapters, which manage the relatyionship between each Data Table and its corresponding database table. I would recommend getting very familiar with all of these various objects before you jump in to developing your actual application. I'll just quickly mention a couiple of things that I think tend to throw people off when working with them

1) Don't confuse Data Sets (and Data Tables) with classic ADO recordsets - they're totally different. You'll need to understand how datasets changes are tracked - the dataset has it's own methods for undoing updates - lots of interesting stuff.

2) The data relations, keys, and things you set in the data set are not a substitute for good database design. You should have good integrity rules in the DB as well. Your Data Set rules are there to help you make sure you stuff is valid before you even try to store it

If you're really, really worried about over-using session storage, consider using View State instead. A lot of people only use view state the way ASP.NET does by default - to persist web control values between round-trips. But you can store any value in ViewState (only has to be strings or integers, if I'm not mistaken.) I've never done this myself, but I think you can persist an entire dataset in ViewState - you only have to serialize it first (should be easily done with the ISerializable interface.

Good Luck