Serializing an object

Next, we create an instance of the car class, set the fields and use the XmlSerializer to write the state of the car object to a file:

Listing 9.1: Using the Serialize() method to serialize an object to an XML file.

void SerializeACar()

{

  XmlSerializer ser = new XmlSerializer(typeof(Car));

  XmlTextWriter writer = new XmlTextWriter("car.xml",
      System.Text.Encoding.UTF8);

  // write a human readable file

  writer.Formatting = Formatting.Indented;

  Car wifesCar = new Car();

  wifesCar.Make = "Ford";

  wifesCar.Model = "Explorer";

  wifesCar.Year = 1997;

  ser.Serialize(writer, wifesCar);

  writer.Close();

}

With two(!) lines of code you have created an XML representation of the Car object. You instantiated an

XmlSerializer for the class you want to serialize. Then you called the Serialize() method with an XmlTextWriter object and the object to serialize and that was it! The XmlTextWriter (discussed in chapter 2) controls where and how the output of the method is written. Imagine how easy to build applications that exchange XML when you can transform your application objects into XML with two lines of code.

The

Serialize() method makes use of the pluggable architecture we have seen throughout the discussion of the System.Xml namespace. It accepts any classes derived from System.IO.Stream, System.Xml.XmlWriter or System.IO.TextWriter, thus allowing a great deal of flexibility where to persist objects to. The following listing shows the class and the XML document of a serialized instance side-by-side.

The XmlSerializer produced an element named after the class of the serialized instance. Each field resulted in a child element with the name of the fields. How was the XmlSerializer able to do that? Remember I said I had a reason to make them public? Here it is: Since we declared all fields public, the XmlSerializer can analyze the type of the object and access each field to get its value. Accessing private and protected fields is possible for locally installed applications because they run with unlimited security permissions by default. Applications running from the network or the Internet are not granted those permissions, but the XmlSerializer is designed to work within those types of applications to enable XML-based message exchange for example. Therefore the XmlSerializer has to restrict itself to the serialize the class members it can access even with no special permission settings.

You are probably (rightfully) concerned about exposing

public fields because they break encapsulation. The good news is that you do not necessarily have to. XML serialization also works with properties as long as they provide read and write accessor methods. It will not process read- or write only properties because the XmlSerializer makes sure it only processes properties that can be transformed both ways. However, if the order of the serialized elements matters, as it does when your class maps to certain XML schema types, your class must not mix properties and fields. The XmlSerializer does not maintain the order of which fields and properties appear in the class definition. It first maps all the fields to the XML document, then all the properties.

BUG WARNING: Version 1.0 of the .NET Framework had a bug that would corrupt the order of serialized properties if the serialized class was written in Visual Basic.NET. The bug was fixed in Version 1.1.