Sunday, March 28, 2010

.NET Serialization Techniques

Serialization modes

·         Binary Serialization

o   Pros:

§  Handles circular references by mapping objects prior to serialization.

o   Cons:

§  Class has to be tagged with serializable attribute

§  Parent, member classes have to be tagged as serializable.

·         May be impossible for certain built-in classes.

o   Note:

§  Classes are opt-in while members are opt out.

·         Meaning the classes will have to be tagged as serializable, but you don’t need to tag each and every member to make them serializable (unlike DataContract).


·         XML Serialization

o   Pros:

§  Easy to use and intuitive.

§  Serialize public fields and properties automatically.

§  Build upon the existing infrastructure and requires little code change or extra attributes, for example binary serialization requires code to be tagged with “serializable” attribute, but not so if you just want to XMLSerialize the same object.

§  Serialized object is readable.

o   Cons:

§  Cannot be used in classes with circular reference.

·         A quick example is a doubly linked list.

§  Will not serialize arrays of generic list (see:

o   Note:

§  Opt out, any public member that should not be serialized has to be [XMLIgnore] tagged.

§  Class must have default constructor that takes no argument.

§  Generic collection must have default accessors. Eg. Stack is not serializable this way, but list is.

§  Will not serialize enum whose:

·         Type is ulong

·         Value is greater than 9,223,372,036,854,775,807


·         ISerializable

o   Pros:

§  Very flexible, it can be made to do anything.

o   Cons:

§  A lot of rewrite and extra codes.

§  Too specific and not generic enough.

·         If you write the serialize method implementation for a type, it “usually” will not work with any other type.

§  It basically demands that you custom write each type serialization and deserialization method.

o   Note:

§  May be simplified with multiple inheritance using AOP


·         Marshall By Value

o   Pros:

§  Scalable.

o   Cons:

§  Cannot store state information on the server

o   Notes:

§  Behaves a lot like the binary serialization with identical pros and cons.

§  Object is transmitted across the network, to the client. Any subsequent calls will be made on the client object itself.


·         Marshall By Ref

o   Pros:

§  Easy and intuitive to use.

§  Object state is stored on the server side.

§  Better abstraction as the object behaves like any other local object.

o   Cons:

§  Repeated use is expensive. A loop that goes through a function call will be made to travel across the network each time!

§  Hides the cross network call round trip a little too well as remote object behaves exactly like a local object, causing unwary programmer to write slow and bloated code.

§  Must inherit from MarshallByRef object, forcing this kind of remoting object to originate from MarshallByRef object (directly or indirectly eg. the object great great grand parent could be MarshallByRef instead of the parent itself).

§  All member reference types must inherit off the same class as well.

o   Note:

§  Very cool concept that abstracts away the hardware layer, unfortunately its drawbacks are equally terrible.


·         DataContract

o   Pros:

§  The latest, currently supported serialization mode for WCF services

§  Easily wired using LINQ to SQL wizard.

o   Cons:

§  Class must have a default construct (ie. Constructor with no parameter)

§  So new that it may not be supported by services or older 3rd party tools that rely on binary serialization.

·         For example:

o   Sql Server Caching.

o   Shared Session in web farms.

o   Older versions of NCache.

§  Cannot automatically resolve circular reference.

§  Every member to be serialized must be tagged [DataMember] – tedious.

§  Each class has to be tagged [DataContract] – tedious.

§  Enumeration member type must be tagged with [EnumMemberAttribute] – (see:

§  Does not serialize .NET specific classes.

o   Note:

§  This is an opt-in serialization technique.

§  WCF does not recognize inheritance from a Data Contract Serialized objects. Derived object must be declared using – [KnownType(Type T)] tag to be recognized.

§  In Linq to SQL UI, circular reference can be turned off by selecting unidirection property, which’ll automatically remove tags on members that potentially cause circular reference.

§  For detail see:


·         NetDataContract

o   Pros:

§  Binary formatter without having to mark the code as serializable. Beware it’ll behave like the old XMLSerializer in this case, except that it will take circular reference.

·         Useful for inheriting from objects that are not tagged serializable.

§  Type checked – whereas wcf services using the default DataContractSerializer gets confused and throws an exception when a child type is passed in as an argument whose parameter is its parent type, NetDataContractSerializer will accept it.

o   Cons:

§  Client has to have the type parameters in the WCF service, ie. You have to share your class libraries.

§  Class has to be tagged with either DataContract + DataMembers attributes or Serializable attributes, or it needs to follow the XML Serializer rules (except that circular reference is allowed in this case). See:

§  Since client has to have your classes, client must also have a .NET CLR, which means client must typically run in Windows.

§  WCF does not support this method out of the box, so a custom attribute implementation is required.

o   Note:

§  Most online example shows using WCF + NetDataContract serialization  using a custom operation attribute.

·         This means every function call will have to be tagged with the netdatacontract attribute, which may be tedious.

§  Alternatively a few actually shows how to declares a WCF end point to use NetDataContractSerializer binding.


No comments:

Post a Comment