Introduction

XmlSerializer, sharpSerializer, and many other serialization engines cannot deserialize types which have no default constructor.
In this article, I'll tell you how to effectively serialize difficult objects which have no default constructor. I'll also explain the differences
between the Custom Serializer Pattern and Substitute Pattern and tell you which one is better and why. At last, I'll show you an example of serialization
of an object without a default constructor into Isolated Storage in WP7 with sharpSerializer, an Open Source serializer for .NET Full, .NET Compact, and Silverlight.

Background

Every mama says: Serializer is not a memory dumper. It should not persist every single byte from the application. During serialization, only vital data
should be stored. There is no need to serialize all the properties and fields of an object. Only those object members should be stored which are necessary
to restore the object state. Other members should be ignored during serialization. They can be restored later from the vital ones. This strategy has two big advantages:

serialized data has smaller size,

serialization is faster.

How to serialize Bitmap, Cursor, Icon, Font, and other types without a default constructor

The simplest answer - don't! These types are complicated, have internal handles, streams, references, and should not be serialized in the whole.

Custom serialization of these types can be done in many ways. Below are two of them presented:

Writing a custom serializer (Custom Serializer Pattern)

Creating a substitute with the default constructor (Substitute Pattern)

Further, I'll explain which one is better and why.

Let's assume there is the following object to be serialized:

publicclass TypeWithoutStandardConstructor
{
// Constructor with parameters
public TypeWithoutStandardConstructor(object data){}
// Some important members
// ...
// Some unimportant members
// ...
}

Pattern 1 - Serializing with a custom serializer

Some third party serialization engines contain a placeholder for custom serializers. Custom serializers are defined and added
to this placeholder (i.e., Dictionary<Type, ICustomSerializer>) before serialization begins. During serialization, the serialization
engine investigates serialized members. If a serialized member is of a special type, the dedicated custom serializer will be used to serialize this member.
If not, the default serialization engine serializes this member.

A custom serializer can serialize the object to a stream and deserialize it from another stream. Its interface could be like this:

During serialization, the serialization engine investigates every serialized type if there is an appropriate custom serializer defined.
If there is one, the member of this type is serialized by the custom serializer. If no custom serializer is found, the member is serialized by the serialization
engine itself. How the serialization engine works is out of the scope of this article. For more information, please refer
to the sharpSerializer project page and search for the chapter "How does sharpSerializer work?".

Advantages of using a custom serializer:

No need to modify serialized classes.

Disadvantages:

Searching for an adequate ICustomSerializer for every serialized type slows the serialization.

Different serialization engines need dedicated custom serializers. There is no single ultimate ICustomSerializer interface.

Custom serializers must be additionally written by a programmer.

Pattern 2 - Serializing with a substitute class

In the Substitute Pattern it is not the TypeWithoutStandardConstructor that is serialized but its substitute which has the default constructor.

sharpSerializer uses this pattern. All vital properties are copied from the original object to the substitute. Fields of the original object are converted
in public properties of the substitute (for performance reasons, sharpSerializer serializes only public properties).

publicclass Substitute
{
// default constructor is required for serialization
public Substitute(){}
// creates substitute from the original
publicstatic Substitute CreateSubstitute(
TypeWithoutStandardConstructor original)
{
// Create substitute instance,
// fill its properties from the original object,
// convert fields of the original object
// in public properties of the substitute
}
public TypeWithoutStandardConstructor CreateOriginal()
{
// create original instance, even without default constructor,
// copy all important members from the substitute,
// calculate unimportent ones
}
// Only important properties and fields of the original
public property VitalProperty1 { get; set; }
// ...
}

The substitute class contains all the vital members of the object. They are copied from the original object in the Substitute.CreateSubstitute() static function.
Then the substitute is serialized. During deserialization, the substitute is reloaded. The original object is created in the substitute's
CreateOriginal() function. The CreateOriginal() function is some kind of object factory.

Advantages of the Substitute pattern:

No need to alter original objects.

No time waste for searching the list with custom serializers.

No low level serialization must be made. Stream reading/writing is made by the serialization engine.

No need to adapt the code if working with different serialization engines.

Disadvantages:

Substitute must also be written by the programmer.

Conversion between the original object and its substitute must be made prior to serialization and after deserialization.

Which one is better? Custom Serializer or Substitute Pattern?

In both patterns, additional code must be written. Either it's a custom serializer or a substitute class. The original object must be modified in neither of them.
Creating substitutes slows the serialization but querying the dictionary with the custom serializers for each serialized type can be a bigger time penalty.

The first certain advantage of the Substitute Pattern is leaving the low level serialization to the serialization engine. The necessity of making
a different custom serializer for every serialization format (XML, binary, JSON) multiplies the complexity of the Custom Serializer Pattern.

The second one is its flexibility. Each serialization engine I know supports serialization of classes with a default constructor and public properties.
Therefore a migration from one serialization engine to another is no problem at all.

In my opinion, Substitute Pattern clearly wins this competition.

Example of serialization of FontFamily to IsolatedStorage in WP7 using the Substitute Pattern and sharpSerializer

System.Windows.Media.FontFamily is a part of the Silverlight library. It does not have the default constructor and must be serialized in a custom way.

sharpSerializer is an Open Source serializer for .NET, .NET Compact, and Silverlight.
It can serialize data into XML and binary format. sharpSerializer uses the Substitute Pattern for serialization.

The interesting part of System.Windows.Media.FontFamily is shown below:

Some words about sharpSerializer

If you are a WP7 programmer, or even not;-), and you need an easy way for storing your app settings, or if you just need to quickly serialize your
business objects between a Silverlight app on WP7 and the full .NET service, then sharpSerializer will not disappoint you.

As a user of the NuGet.org plug-in for VS, just search for "sharpserializer"
after clicking the context item "Add library package reference.." in your Solution Explorer.