locked
DataContractSerialization RRS feed

  • Question

  • User-191123834 posted

    I am new to serialization in .Net.

    I have an application that uses DataContracts/DataMembers and Serialization to store information entered in a tab control.  There are 8 tabs in the control (therefore 8 aspx pages).  The final tab is used to write the information to disk.

    I am trying to understand: 

    When should serialization be used in a web app? 

    The objects are stored in memory not on disk.  Is this another means of passing objects between aspx pages?  If so when should serialization be used vs. session objects? 

    How long is the serialized object retained in memory? 

    Can I get a simple example of how to serialize in one page and deserialize the object in another page?

    I've read many blogs regarding serialization but have yet to find a simple example and none of them explain when serialization should be used vs. session objects?

    Any help would be greatly appreciated.

    Thanks in advance.

    Thursday, January 21, 2010 1:12 PM

Answers

  • User-952121411 posted

    I'm also curious how long a serialized object will remain in memory.  The application we use has many tabs and it could take some time for the transaction to be completed.  When is the serialized object deleted from memory? 
     

    Don;t confuse serializing objects and an object stored in memory; they are (2) separate things.  You could serialize an object and never have it stored in memory at all.  'Memory' as referenced commonly in ASP.NET applications, is that of the web app server's memory and is typically associated with Application or Session variables.  Therefore, how long does the object you place in Session or memory stay there?  Well if it is in a Session variable, it will remain in memory and accessible for the life of the session on the server; or more realistically for the life of the user's session and their individual interaction with your site.  Application variables persist longer than session variables and span across all applications of the same web on the server.

    You mentioned you are familiar with Session objects, but you may want to read a little more on State Management on the server (memory as we are calling it here); take a look to the link below for more information:

    ASP.NET State Management Recommendations:

    http://msdn.microsoft.com/en-us/library/z1hkazw7.aspx

    Lastly, an object must be serialized to make its types transportable across HTTP for example.  The process of serializing types into say a Base64 encoded string or XML is so that it can be transported across the wire.   Here are a few links on serialization that might help:

    Serialization in the .NET Framework:

    http://www.15seconds.com/issue/020903.htm

    Serialization: the What and the Why:

    http://www.devsource.com/c/a/Techniques/Serialization-the-What-and-the-Why/

    Serialization in .NET:

    http://devcity.net/Articles/113/1/dotnet_serialization.aspx

    A quick way to Object Serialization:

    http://west-wind.com/weblog/posts/251.aspx

     

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, January 22, 2010 9:47 AM

All replies

  • User-952121411 posted

    The best short answer I can give to your question, is to store objects in Session when they only need to persist for the lifetime of the user interacting with the web application from page to page within a single session.

    Serialization of objects can be used for many reasons, but the (2) most typically used reasons are for serializing the object to store in the database, or to serialize an object to send across the wire to a web service, WCF service, .NET Remoting, etc.  The reason for storing an object in a database is if you need that object to persist for longer that a single users web session and that object is going to need to be restored in the future.  One possible use of this might be in a long data entry process, where the user may want to quit in the middle and come back to the same point at a later time.  The other reason to serialize objects is so that they can be passed via HTTP, TCP, or similar protocols to services.  You will find that passing objects previously designed with non-serializable types can become an obstacle when creating new services.

    My thoughts based on your description is that storing your object(s) in session and then pulling back out of session when needed is all you need to do.  If you need any more information about Session State, take a look at the following:

    ASP.NET Session State Overview:
     
     
    Hope this helps! Smile<!---->
    Thursday, January 21, 2010 4:59 PM
  • User-191123834 posted

    Thank you for the quick response.

    I'm pretty familar with session state and use it frequently.  The origin of my questions were that I am given an application to modify that makes heavy use of serialization.  I was attempting to identify why it was used so heavily.  I believe it is for the reason you mentioned (to pass to a web service or another layer that references it to update the database).  

    I could still use a simple example of a data contract and serialization (if such a thing is possible).

    I'm also curious how long a serialized object will remain in memory.  The application we use has many tabs and it could take some time for the transaction to be completed.  When is the serialized object deleted from memory? 

    Thanks again for your assistance.  

    Friday, January 22, 2010 8:56 AM
  • User-952121411 posted

    I'm also curious how long a serialized object will remain in memory.  The application we use has many tabs and it could take some time for the transaction to be completed.  When is the serialized object deleted from memory? 
     

    Don;t confuse serializing objects and an object stored in memory; they are (2) separate things.  You could serialize an object and never have it stored in memory at all.  'Memory' as referenced commonly in ASP.NET applications, is that of the web app server's memory and is typically associated with Application or Session variables.  Therefore, how long does the object you place in Session or memory stay there?  Well if it is in a Session variable, it will remain in memory and accessible for the life of the session on the server; or more realistically for the life of the user's session and their individual interaction with your site.  Application variables persist longer than session variables and span across all applications of the same web on the server.

    You mentioned you are familiar with Session objects, but you may want to read a little more on State Management on the server (memory as we are calling it here); take a look to the link below for more information:

    ASP.NET State Management Recommendations:

    http://msdn.microsoft.com/en-us/library/z1hkazw7.aspx

    Lastly, an object must be serialized to make its types transportable across HTTP for example.  The process of serializing types into say a Base64 encoded string or XML is so that it can be transported across the wire.   Here are a few links on serialization that might help:

    Serialization in the .NET Framework:

    http://www.15seconds.com/issue/020903.htm

    Serialization: the What and the Why:

    http://www.devsource.com/c/a/Techniques/Serialization-the-What-and-the-Why/

    Serialization in .NET:

    http://devcity.net/Articles/113/1/dotnet_serialization.aspx

    A quick way to Object Serialization:

    http://west-wind.com/weblog/posts/251.aspx

     

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, January 22, 2010 9:47 AM