XML Serialization in ASP.NETBy Anthony Hart
In the past, maintaining the state of an object in ASP often required some very inventive and painstaking code. In the brave new world of .NET, however, Object Serialization offers us a comparatively easy way to do just that, as well as some other useful tasks.
As a kid, I remember waking up on many a cold morning and stumbling into the kitchen with my eyes half-closed, looking forward to whatever Mom had prepared for breakfast, only to find an anticlimactic bowl of steaming hot just-add-boiling-water instant oatmeal waiting for me on the table. At least I wasn't like the more unfortunate kids whose mothers force-fed them that white silt of death, powdered milk. I am absolutely certain that something must go seriously awry in the dehydration process of milk because upon rehydration, that stuff is just plain nasty.
Be that as it may, I think that at least one of the developers involved in creating the .NET Framework must have been one of those abused children. I see powdered milk fingerprints all over some of the new data management techniques in .NET. Then again, in an age of dehydrated/rehydrated food products, what could be more logical than dehydrated/rehydrated data?
The technique to which I refer is called "Object Serialization". Object Serialization is a process through which an object's state is transformed into some serial data format, such as XML or a binary format, in order to be stored for some later use. In other words, the object is "dehydrated" and put away until we need to use it again. Let's look at an example to clarify this idea a little further. Suppose we have an object defined and instantiated as shown below:
Let's say that for some reason, we wanted to save a copy of this object just as it is at this very moment. We could serialize it as an XML document that would look something like this:
Then, at some later time when we needed to use the object again, we could just deserialize ("rehydrate") it and have our object restored to us just as it was at the moment we serialized it.
Why All This Dried Food?
"This serialization and deserialization is all well and good," you may be saying at this point, "but what can it be used for in real world web applications?" Very good question. What would be the sense of dehydrating a glass of milk just to rehydrate it and then dehydrate it again without drinking any? Never mind that it'll probably taste like the inside of your little brother's sock drawer (maybe I should have come up with a more tasty dehydrated food for this analogy). Some good uses for serialization/deserialization include:
- Storing user preferences in an object.
- Maintaining security information across pages and applications.
- Modification of XML documents without using the DOM.
- Passing an object from one application to another.
- Passing an object from one domain to another.
- Passing an object through a firewall as an XML string.
These are only a few of the many possibilities that serialization opens up for us.
The Dehydration Process
"Okay, okay, I get the picture," you may be muttering now, "but how do I do it?" I'm going to walk you through a simple example of serializing an object to be saved to disk as an XML file. Keep in mind that in .NET we can serialize objects into a binary format or SOAP format as well as into XML, but we will focus solely on XML for this article for the sake of brevity. Also, the object in the example is obviously very simplistic and wouldn't be practical in the real world, but it will serve as a means to clearly illustrate how to serialize an object. The same principles used in this example can then be applied to more complicated tasks. Note that all the code used for this example is available for download at the end of this article; also a xmlser.aspx">live demo is available).
First of all, let's take a look at the class that is the blueprint for our object (this snippet can
be found in the file,
This looks pretty similar to the class we saw earlier but with a few adjustments. First of all,
notice the lines that say,
<XMLElement.... These are
.NET attributes and tell the serializer where the various members of this object will appear in the
XML document and what they will be named. Without these, serialization cannot take place. The next
difference you will notice is that there are two methods declared in the class called,
Goodbye(). These really have no bearing on the serialization that will take place,
but we will use them later to demonstrate the state of the object at a given point in the
Next let's look at the code that actually instantiates the object and then serializes it.
First of all, we declare and instantiate an
XMLSerializer object. You'll notice that we
had to tell it right from the onset, using the
GetType() function, what type of object
it's going to be serializing. Next you see that we assign values to the
properties of the
Person object we instantiated. Then we output to the ASP.NET page what
the properties are set to by calling the
Goodbye() methods of
Person object. Remember that this is only so that we can see what's happening with the
object during this process. Next comes the good stuff: We instantiate a
object and tell it that it will be writing to a file called,
lucky.xml. We then call the
Serialize() method of the
XMLSerializer object and send it our
object to be serialized as well as the
StreamWriter object so it will write the resulting
XML to the file specified. Then we close the
StreamWriter, thereby closing the file.
That's it. If everything works correctly, an XML file (
lucky.xml) will be written to
disk. It should look like this:
Notice that the names of the XML elements are exactly as we specified in the
<XMLElement()> attributes in the class earlier.
In Part 2 we'll examine how to "rehydrate" our XML into an object