SAY NO TO SERIALIZATION

If you want to know hot to get your application to save information to disk or the registry, then the correct phrase is Serialization. This article in contrast discusses on not using serialization.

Cons of using Serialization

Serialization forces to design classes in a certain way

XML serialization only works on public methods and fields, and on classes with public constructors. That means classes need to be accessible to the outside world. We cannot have private or internal classes, or serialize private data. In addition, it forces restrictions on how we implement collections.

Serialization is not future-proof for small changes

If the classes marked are [serializable], then all the private data not marked as [NonSerialized]will get dumped. We have no control over the format of this data.  If  private variable name is changed then code will break.

Serialization is not future-proof for large changes

Type information is stored as part of the serialization information.  If we change class names or strong name our assemblies, we are going to hit all sorts of problems.

Serialization is not Secure

Using XML serialization is inherently insecure. Classes need to be public, and they need to have public properties or fields. In addition, XML serialization works by creating temporary files. If we think we are creating temporary representations of our data (for example, to create a string that we are going to post to a web service), then files on disk will pose a potential security risk. If, instead, we implement theISerializable interface and are persisting sensitive internal data, then, even if we are not exposing private data through classes, anyone can serialize our data to any file and read it that way, sinceGetObjectDatais a public method.

Serialization is not efficient

XML is verbose. And, if you are using the ISerializable interface, type information gets stored along with data. This makes serialization very expensive in terms of disk space.

Serialization is not faster

Create a class that contained two double values. I created 100,000 instances of this class, stored them to disk, and then read them back again. I did this two ways. First of all, I did it the proper way, by implementing ISerializable, creating a Binary Formatter, and using the Serializeand Deserializemethods. Secondly, I did it the dirty way, by blasting the data straight out into aStream. Which way was faster? Perhaps not surprisingly, the dirty way, About 50 times faster.