Mark Wilson I am the creator of TopXML. I am available for international and local (Australia) contracts. I am a Solution Architect/Business Analyst. I have worked in IT in several countries (NZ, Australia, South Africa, UK) building and training teams for government and very large non-governmental organizations. I am ex-Microsoft Consulting Services. I wrote the first book on Microsoft XML published in 2000 called XML Programming with VB and ASP. Most recently I have been building tools for the SEO industry. Ask me for a 37 point SEO health-checkup for your website.
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.
