Hi Tobias,
In english, I like to think of serializing as zipping the contents
of an object and then unzipping those contents at a later date. In the
interim the serialized (zipped) object can be stored on a disk or a
database.
The official version is worth reading so, I've cut & pasted some
relevant entries from the documentation. There are plenty of examples
online and within the MSDN website in addition to the VSNET help.
The official version:
Serialization is the process of converting the state of an object into
a form that can be persisted or transported. The complement of
serialization is deserialization, which converts a stream into an
object. Together, these processes allow data to be easily stored and
transferred.
The .NET Framework features two serializing technologies:
Binary serialization preserves type fidelity, which is useful for
preserving the state of an object between different invocations of an
application. For example, you can share an object between different
applications by serializing it to the Clipboard. You can serialize an
object to a stream, to a disk, to memory, over the network, and so
forth. Remoting uses serialization to pass objects "by value" from one
computer or application domain to another.
XML serialization serializes only public properties and fields and
does not preserve type fidelity. This is useful when you want to
provide or consume data without restricting the application that uses
the data. Because XML is an open standard, it is an attractive choice
for sharing data across the Web. SOAP is likewise an open standard,
which makes it an attractive choice.
Why would you want to use serialization?
The two most important reasons are to persist the state of an object
to a storage medium so an exact copy can be re-created at a later
stage, and to send the object by value from one application domain to
another. For example, serialization is used to save session state in
ASP.NET and to copy objects to the Clipboard in Windows Forms. It is
also used by remoting to pass objects by value from one application
domain to another.
You should consider serialization when designing new classes, because
a class cannot be made serializable after it has been compiled. Some
questions to ask are: Will this class need to be sent across
application domains? Will this class ever be used with remoting? What
will users do with this class — might they derive a new class from
mine that needs to be serialized? When in doubt, mark the class as
serializable. It is probably better to mark all classes as
serializable unless any of the following are true:
The class will never cross an application domain. If serialization is
not required and the class needs to cross an application domain,
derive the class from MarshalByRefObject.
The class stores special pointers that are only applicable to the
current instance of the class. If a class contains unmanaged memory or
file handles, for example, ensure these files are marked as
NonSerialized, or don't serialize the class at all.
Class data members contain sensitive information. In this case, it is
advisable to mark the class as serializable, but to mark the
individual data members that contain sensitive information as
NonSerialized. Another alternative is to implement the ISerializable
interface and serialize only the required fields.
Be aware of the security implications of marking a class as
serializable. A Link Demand or an Inheritance Demand for a
CodeAccessPermission on a class or class constructor can be bypassed
by default or custom serialization that implements a corresponding
demand for the same CodeAccessPermission. If a class has a Link Demand
for a permission, the runtime checks only the immediate caller to
verify that the caller has been granted the permission. The .NET
Framework class library code is signed with the Microsoft strong name
and is always granted full trust. Any code can use code that is
granted full trust to bypass link-time security checks. For example,
in the case of serialization, malicious code that does not have the
required serialization permission can call one of the fully trusted
..NET Framework formatters, such as BinaryFormatter, and bypass the
link-demand check for the permission.
[************** Why,Why,Why?? **************]
It is often necessary to store the value of fields of an object to
disk and then retrieve this data at a later stage. Although this is
easy to achieve without relying on serialization, this approach is
often cumbersome and error prone, and becomes progressively more
complex when you need to track a hierarchy of objects. Imagine writing
a large business application containing many thousands of objects and
having to write code to save and restore the fields and properties to
and from disk for each object. Serialization provides a convenient
mechanism for achieving this objective with minimal effort.
The common language runtime manages how objects are laid out in memory
and provides an automated serialization mechanism by using reflection.
When an object is serialized, the name of the class, the assembly, and
all the data members of the class instance are written to storage.
Objects often store references to other instances in member variables.
When the class is serialized, the serialization engine keeps track of
all referenced objects already serialized to ensure that the same
object is not serialized more than once. The serialization
architecture provided with the .NET Framework correctly handles object
graphs and circular references automatically. The only requirement
placed on object graphs is that all objects referenced by the object
that is being serialized must also be marked as Serializable (see
Basic Serialization). If this is not done, an exception will be thrown
when the serializer attempts to serialize the unmarked object.
When the serialized class is deserialized, the class is re-created and
the values of all the data members are automatically restored.
