locked
How do I use a datacontext accross multiple pages/postbacks

    Question

  • I have an application where a user creates an order.  The order process is fairly complex, it contains data that is written to five different tables.  My objective is to allow the user to create an entire order without writing anything to the database.  Once the user clicks save I want to write the whole thing at once.  How do I accomplish that?  Do I need to save a data context in a session variable? 
    Thanks
    Friday, April 10, 2009 3:47 PM

Answers

  • Thanks for the clarification - I now have a better understanding of what you meant. Although the datacontext itself should be short-lived it is perfectly ok to keep instances of entity classes around so you can generate your entity classes in memory, keep them in session and/or viewstate. Once you're ready to submit to the database you create a datacontext instance, add new entity objects or attach modified entity objects and submit changes.

    In other words, if you use entity objects to store data collected from users before submitting to the database you need to track entity state (new/modified/deleted etc) yourself across postbacks/page lifecycles and then use the L2S datacontext to read/write from the database.

    L2S built-in entity state tracking is better suited for use in 2-tier scenarios, e.g. a winforms/wpf app that interact directly with the database rather than web app scenarios.


    Kristofer - Huagati Systems Co., Ltd. - www.huagati.com
    • Marked as answer by Sam2 Friday, April 17, 2009 3:52 PM
    Friday, April 17, 2009 3:33 AM

All replies

  • No, don't keep the datacontext around. Make it short-lived - create when needed and dispose of when not needed.
    Kristofer - Huagati Systems Co., Ltd. - www.huagati.com
    Saturday, April 11, 2009 3:22 AM
  • Microsoft, please answer this.

    Thank you.
    Thursday, April 16, 2009 5:55 AM

  • You may find Matt Warren's answer in this thread useful:
    http://social.msdn.microsoft.com/forums/en-US/linqprojectgeneral/thread/ea6fe19c-cd21-40d1-b005-750af6632bfe/

    This thread is also on the same topic, but does not contain any answers from Microsoft:
    http://social.msdn.microsoft.com/Forums/en-US/linqprojectgeneral/thread/5db5ac37-1cc3-4500-a778-955d2a80e7f6

    ..and finally, the MSDN library documentation for the DataContext class says "In general, a DataContext instance is designed to last for one "unit of work" however your application defines that term. A DataContext is lightweight and is not expensive to create. A typical LINQ to SQL application creates DataContext instances at method scope or as a member of short-lived classes that represent a logical set of related database operations.".


    Kristofer - Huagati Systems Co., Ltd. - www.huagati.com
    Thursday, April 16, 2009 8:48 AM
  • Hi KristoferA

    Thank you for your response.  I think you've been quite clear that a datacontext is a short lived object.  But that answers only a very small part of my question.  Here again is the rest:
    My objective is to allow the user to create an entire order without writing anything to the database.  Once the user clicks save I want to write the whole thing at once.  How do I accomplish that? 
    What are best practices for what I want to do?  What I described is a common scenario in business applications.
    My frustration stems from the fact that with one eye I read how Linq (to-sql) is  a "repository" with a robust infrastructre to track entity state.  I understand the framework can maintain state for multiple objects and write them to the database in a single call (i.e. InsertOnSubmit).
    With the other eye (the one thats reading to this thread) I read how a datacontext is a short lived object with no real function other than to open a connection to a database and run the equivelent of a stored proc.
    So there is a huge disconnect in the stated functionality of the product versus the documentation on how it is to be used.

    Thanks for your time.
    Thursday, April 16, 2009 3:59 PM
  • Thanks for the clarification - I now have a better understanding of what you meant. Although the datacontext itself should be short-lived it is perfectly ok to keep instances of entity classes around so you can generate your entity classes in memory, keep them in session and/or viewstate. Once you're ready to submit to the database you create a datacontext instance, add new entity objects or attach modified entity objects and submit changes.

    In other words, if you use entity objects to store data collected from users before submitting to the database you need to track entity state (new/modified/deleted etc) yourself across postbacks/page lifecycles and then use the L2S datacontext to read/write from the database.

    L2S built-in entity state tracking is better suited for use in 2-tier scenarios, e.g. a winforms/wpf app that interact directly with the database rather than web app scenarios.


    Kristofer - Huagati Systems Co., Ltd. - www.huagati.com
    • Marked as answer by Sam2 Friday, April 17, 2009 3:52 PM
    Friday, April 17, 2009 3:33 AM
  • Hi,

    I understand that we can keep entity classes in session and use datacontext in the very end step ( last page ) to submit data to the table , but can you please think of another use case where we need to add data to a many to may relation table related to the entity in one of the middle steps then how will we do it without using datacontext in that step.

     

    example  , User table , sector table , users_sector table ( many to many)

     

     

     

     

    Wednesday, April 20, 2011 8:55 AM