Persisting form data with one to many relationship

Discussion in 'ASP .Net' started by Diane Yocom, May 11, 2004.

  1. Diane Yocom

    Diane Yocom Guest

    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
     
    Diane Yocom, May 11, 2004
    #1
    1. Advertising

  2. 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
     
    =?Utf-8?B?UmljaA==?=, May 12, 2004
    #2
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Marco Ippolito
    Replies:
    0
    Views:
    2,589
    Marco Ippolito
    Oct 11, 2004
  2. Anna
    Replies:
    1
    Views:
    598
    B. Comrie
    Feb 18, 2005
  3. Mirko
    Replies:
    0
    Views:
    2,305
    Mirko
    Oct 12, 2006
  4. Wolfgang Meiners
    Replies:
    6
    Views:
    335
    Wolfgang Meiners
    May 3, 2010
  5. Jim Thomason
    Replies:
    3
    Views:
    163
    Topmind
    Oct 2, 2004
Loading...

Share This Page