- Chapter 10: XML Serialization
- Different Types of Serialization
- How Is Serialization Used in ASP.NET?
- An Overview of XML Serialization
- XML Serialization at Work in ASP.NET
- Chapter Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
How Is Serialization Used in ASP.NET?
Now that you have a good idea of what serialization is and what types of serialization are offered by the .NET Framework, let's take a brief tour of the various ways that serialization is used behind-the-scenes in ASP.NET. Most of the serialization that is built-in to ASP.NET requires no direct interaction with the average ASP.NET developer; however, having a good understanding of what is going on behind the scenes helps you make an informed decision when it comes to certain performance and scalability issues. As you will see, the ASP.NET run-time uses many different types of serialization, depending on what type is best-suited for any given situation.
Session State
As you might or might not be aware, ASP.NET offers three different storage mechanisms for session state:
In-process
Out-of-process as a Windows service
Out-of-process in a SQL server database
The default method of session state storage is in-process, which uses no serialization. Instead, objects that are stored in session state using this method are simply held in memory in the same process that the ASP.NET application in question is running in.
With the out-of-process as a Windows service method, session state is stored in memory by the ASP.NET State service. This service can run on the same physical server as the ASP.NET application that uses it, or it can run on a separate server that is accessed over a Local Area Network (LAN) by ASP.NET whenever it needs to store or retrieve session state data. The support for remote session state servers allows for a dedicated session state server to be shared by all the servers in a web farm, for example.
Because it is problematic at best to move a live object instance between processes on the same machine, and impossible to move a live object instance across the network to a different machine, the session state service cannot take the easy way out that the in-process method does by simply storing a reference to an already-in-memory object. Instead, when this storage method is selected (in the Web.config file), ASP.NET uses the BinaryFormatter object to serialize the object placed in session state to a binary stream that is sent to the session state service under the SessionID key for the current user. The binary serialization allows for quick and memory-efficient storage of an object, but the serialization process obviously takes more time and processing power than simply storing a reference to an object that is already in memory. Therefore, you should carefully consider which session state storage is right for your situation.
Similar to the previous method, the out-of-process in a SQL server database method also uses binary serialization to store session data, but in this case, the data is stored in a table in the SQL server's tempdb database. This adds both the extra overhead and the extra reliability of SQL server over the session state service previously mentioned.
View State
If you've done any ASP.NET development, you might have noticed a hidden form field called __VIEWSTATE embedded in the HTML generated by most web forms. This field contains a compact text serialization of the state of the server controls on that web form. ASP.NET uses the view state to compare a control's state to its previous state to see if it needs to raise any events for that control (due to the text property being changed, for example). The contents of the __VIEWSTATE field are generated by the LosFormatter, which is specifically designed to produce an extremely compact ASCII serialization that's suitable to include in web forms while taking up a minimum amount of bandwidth. The LosFormatter is intended only for internal use during the lifetime of a web request; it is not recommended to persist the serialization produced by this object for any significant length of time.
XML Web Services
XML Web Services use shallow serialization, involving only the public read/write properties of an object, much like XML serialization. However, the result is specific to the SOAP standard, which is an agreed-upon standard for data transport and method calls using XML. Some SOAP-related attributes in the System.XML.Serialization namespace allow customization of the generated code.
What About Configuration Files?
As you learned more about XML serialization, you might have wondered whether the XML-based configuration files in the .NET Framework (such as Web.config) use XML serialization. The answer appears to be no. Configuration files in .NET are read by a series of configuration section handlers that are each responsible for their own section of the configuration file (sessionState is one such section in the Web.config file). Unless Microsoft decides to release the source code to the .NET Framework, there's no way of being 100 percent certain whether the built-in section handlers use XML serialization or not. However, each section handler must implement the IConfigurationSectionHandler interface, which specifies a single method, Create. The Create method accepts an XmlNode object that is not friendly to the XmlSerializer, causing namespace errors whenever it is used as the source for deserialization. It might be possible to get a custom configuration section handler to work with XML serialization, but it appears to be more work than just using the XmlNode object directly.