Microsoft Developer Network > Forums Home > Archived Forums Forums > LINQ Project General > How do I use a datacontext accross multiple pages/postbacks
Ask a questionAsk a question
 

AnswerHow do I use a datacontext accross multiple pages/postbacks

  • Friday, April 10, 2009 3:47 PMSam2 Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    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

Answers

  • Friday, April 17, 2009 3:33 AMKristoferA - Huagati Systems Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Answer

    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 bySam2 Friday, April 17, 2009 3:52 PM
    •  

All Replies

  • Saturday, April 11, 2009 3:22 AMKristoferA - Huagati Systems Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Proposed Answer
    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
  • Thursday, April 16, 2009 5:55 AMSam2 Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Microsoft, please answer this.

    Thank you.
  • Thursday, April 16, 2009 8:48 AMKristoferA - Huagati Systems Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     

    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 3:59 PMSam2 Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    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.
  • Friday, April 17, 2009 3:33 AMKristoferA - Huagati Systems Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Answer

    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 bySam2 Friday, April 17, 2009 3:52 PM
    •