Home.NET Delving Deeper into Serialization with .NE...
Delving Deeper into Serialization with .NET
In "Serialization with .NET," we began by serializing a simple string. Then, we moved on to serializing custom types and examined how a class can participate in the serialization and deserialization processes using the OnSerializing, OnSerialized, OnDeserializing and OnDeserialized attributes. In this article, we'll continue to examine serialization with .NET.
So far, we've only serialized simple classes that don't inherit from anything besides Object. However, it's important to take note of the combination of serialization and inheritance. To experiment, let's create two classes, one of which will inherit from the other. The first will be Shape and will represent any sort of shape. It will have a private field named area with an associated property, Area. The second will be ThreeDimensionalShape and will represent a three-dimensional shape. It will have a private field named volume, with can be accessed through the property Volume. Here are the two classes:
using System;
public class Shape
{
private double area;
public Shape(double area)
{
this.area = area;
}
public double Area
{
get
{
return area;
}
}
}
public class ThreeDimensionalShape : Shape
{
private double volume;
public ThreeDimensionalShape(double area, double volume)
: base(area)
{
this.volume = volume;
}
public double Volume
{
get
{
return volume;
}
}
}
Now, let's apply the Serializable attribute to Shape so that it can be serialized:
Now we have a serializable Shape class, but does the fact that Shape is serializable make ThreeDimensionalShape serializable as well? In other words, does a class inherit the ability to be serialized? To find out, let's write and run some code that attempts to serialize instances of both classes:
using System;
using System.IO;
using System.Runtime.Serialization.Formatters.Binary;
class InheritanceAndSerialization
{
public static void Main(string[] args)
{
// Create a ThreeDimensionalShape
ThreeDimensionalShape cylinder = new ThreeDimensionalShape(12.57, 3.14);
// Serialize cylinder
MemoryStream myStream = new MemoryStream();
BinaryFormatter formatter = new BinaryFormatter();
formatter.Serialize(myStream, cylinder);
myStream.Close();
Console.WriteLine("Cylinder serialized.");
}
}
When we run the above code, we get a nasty error:
Unhandled Exception: System.Runtime.Serialization.SerializationException:Type ThreeDimensionalShape is not marked as Serializable.
...
So, no, a class that wants to be serialized must apply the Serializable attribute, even if its base class applies the attribute. If we modify the ThreeDimensionalShape class by applying the attribute, then the above code runs fine:
[Serializable]
public class ThreeDimensionalShape : Shape
{
...
}
Cylinder serialized.
Note that ThreeDimensionalShape does not have access to Shape's area field since we have it set as private. However, when a ThreeDimensionalShape is serialized, area is serialized too, and when the object is deserialized, all of the serializable internal data is restored. .NET handles all of this for us, so properly serializing child class instances is as simple as marking the child class as Serializable. .NET handles all of the work behind the scenes.
There is still one situation we haven't looked at, though: can a child class be serialized if its parent class isn't marked with the Serializable attribute? Remove the Serializable attribute from Shape and run the above code again:
Unhandled Exception: System.Runtime.Serialization.SerializationException:Type Shape in assembly _Serialization, Version=0.0.0.0, Culture=neutral is not marked as serializable.
...
No, it would appear that it's not possible to serialize an instance of a class whose parent class isn't serializable, even if the child class is itself serializable. .NET's serialization mechanisms work their magic only if we play by the rules, and the rules state that in order for instances of a class to be serializable, its base class must also be serializable. That said, however, it is still possible to serialize an instance of such a class, though the solution isn't pretty since .NET won't automatically do the work for us.
So far, the serialization process has been mostly handled for us. All that we've done is apply attributes where necessary, and .NET has figured out how to do everything on its own. Where we've needed to intervene and participate in the serialization and deserialization processes, we've created methods that are called at the proper time. This automation is generally a good thing. However, it is possible to gain more direct control over the processes of serialization and deserialization. This can be done by implementing the ISerializable interface.
Recall from the previous part how we needed more control over the User class. The class defined a DateTime called sessionStartTime that was marked with the NonSerialized attribute. Since the value of this member isn't stored, we needed to give it an appropriate value upon deserialization. This was accomplished through the OnDeserializing attribute and a simple method. The method, called during the deserialization process, set sessionStartTime to the current date and time. This got the job done, but we could also have implemented ISerializable. Let's revisit the example and reconstruct User to implement ISerializable. Here is the original User class, without the OnDeserializing fix:
using System;
[Serializable]
public class User
{
private string name;
private DateTime sessionStartTime;
public User(string name)
{
this.name = name;
sessionStartTime = DateTime.Now;
}
public string Name
{
get
{
return name;
}
}
public DateTime SessionStartTime
{
get
{
return sessionStartTime;
}
}
}
Before, because we did not want sessionStartTime to be serialized, we applied the NonSerialized attribute, which prevented .NET from storing the field's value. Now, however, we don't have to apply the attribute. The ISerializable interface defines a method called GetObjectData. In this method, we specify exactly what is to be serialized and how. Only what we specify to be serialized is serialized; everything else is not. Here are the changes required for User to implement the ISerializable interface:
...
using System.Runtime.Serialization;
[Serializable]
public class User : ISerializable
{
...
public virtual void GetObjectData(SerializationInfo info, StreamingContext context)
{
info.AddValue("name", name, typeof(string));
}
}
Notice that GetObjectData has no return type and accepts two parameters: a SerializationInfo and a StreamingContext. The former is what's important here. It contains (or needs to contain, rather) information about the members to be serialized. To add data, the AddValue method is called, which accepts the name of the data, the value of the data and the type of the data. Here, we specify that the name field is to be serialized. Also, it's important that the method be virtual, as we'll see later.
Now, an instance of User can be serialized. However, we need to provide a way for an object to be deserialized as well; this is not done for us. We have to pull our value back out and assign it to the proper place. Additionally, we need to give sessionStartTime a value as well. This is all done through a constructor, whose parameters match the parameters of GetObjectData. The constructor is automatically called upon deserialization, and if it's absent, an exception will be raised. Here's the required code:
Notice how the new constructor is protected. This is to prevent an external source from manipulating private data. Otherwise, information could be loaded with undesirable values.
Now, User is ready for serialization and deserialization:
using System;
using System.IO;
using System.Runtime.Serialization.Formatters.Binary;
class UsingISerializable
{
public static void Main(string[] args)
{
// Create a User
User dan = new User("Dan");
Console.WriteLine("{0}, logged on since {1}.", dan.Name, dan.SessionStartTime);
// Serialize dan
MemoryStream myStream = new MemoryStream();
BinaryFormatter formatter = new BinaryFormatter();
formatter.Serialize(myStream, dan);
// Deserialize dan
myStream.Position = 0;
dan = (User)formatter.Deserialize(myStream);
myStream.Close();
Console.WriteLine("{0}, logged on since {1}.", dan.Name, dan.SessionStartTime);
}
}
Dan, logged on since 8/3/2007 7:09:58 PM.
Dan, logged on since 8/3/2007 7:09:59 PM.
Earlier, we looked at inheritance with .NET's automatic method of serialization. .NET handled the private data defined by our sample base class, Shape. However, with ISerializable, this isn't the case. For a child class to be properly serialized, it needs to override GetObjectData, wherein it needs to call its base class' GetObjectData method (this is why we set User's as virtual). The child class also needs to call its parent class' constructor. Let's create a class called Administrator, which will inherit from User, to demonstrate this:
public override void GetObjectData(SerializationInfo info, StreamingContext context)
{
base.GetObjectData(info, context);
// add data to info
}
}
So, why use ISerializable over .NET's default method of serialization? Actually, in most cases, you shouldn't. As you've probably noticed, using ISerializable is far more complicated and messier, and it's actually slower. Unless you have a really good reason to use ISerializable, stick with the default method. If you need control over the serialization and deserialization processes, simply use the attributes discussed in the last part. Moreover, the attribute approach is more readable. Rather than looking through the GetObjectData method to discover what members are serialized and what members are not, one can just look at the member itself.
Conclusion
Serialization is a powerful technique for persisting objects. In the first part, we examined how to use .NET's default, attribute-based serialization method, and we saw how to participate in this process by using special attributes and methods. In this part, we looked at how inheritance affects the serialization process. We also looked at the ISerializable interface, which offers a more manual approach to serialization. However, serialization does not end there: there are many more serialization-related features to the framework that merit looking into.
Serialization with .NET
