Why should I not make a class Serializable?

Question

I'm storing some objects in my viewstate and I was wondering if there are any disadvantages to making a class Serializable?

Is it bad practice to make all of the classes Serializable?

Lachance

You should avoid storing anything in the viewstate that doesn't have to be there – Tetrastich

Answer 1

Firstly. Avoid viewstate.

Generally serialization (textual) is used for transferring objects.

You should avoid marking any class as serializable that is not a DTO (Data transfer object) or message class. We do this for several reasons. What ever picks up your class in serialized format may not have the method information (which is in the original assembly) of a non DTO class. Secondly, a class may reference a resource (DB connection, file handle, etc) Do NOT serialize these, since de serialization does not re-establish resource connections and state, unless explicitly designed for, but is still a bad idea.

So in summary: Do NOT serialize when you have contextual methods and storing data for a thrid party to use. (Like a service response with methods is a bad idea). And do NOT serialize when the class contains a resource reference. Keep your serializable object clean from methods as much as possible. This might involve a little re factoring into a service type pattern.

Do serialize DTO's and messages.

This is more of a design choice.

Amieva

Binary (non-text) serialisation isn't dfferent at all, and can absolutely be platform independent. The problem is things like BinaryFormatter, which is just one binary serializer. – Metaphor

(I agree with your other points, though; I'll try to remember to +1 impetus when I have more votes) – Metaphor

I never said it was not platform dependent, just slightly different. You have to consider special cases. Binary serialization preserve instance identity. (For what its worth) and textual serialization can be seen as a memory "clone" that is saved to disc – Amieva

you emphasised that textual serialization is platform agnostic; this implies a difference. Re "instanced identity" (comment), again this has nothing whatsoever to do with binary vs not; there are textual serializers that preserve identity (DCS in full-graph mode), and there are binary serializers that do not. My point: you are describing some artificial differences between binary/text serialization, which are actually simply features of different serializers (which can themselves be binary or text based). – Metaphor

True that. I am referring to the out the box .Net stuff here. Removed the criminal sentence. – Amieva

Is it safe to say that Controller and Services should not be Serialized as well? – Domett

Answer 2

It is a good practice to make all classes that are actually Serializable as Serializable. I would just use common sense, and set it for those classes that are intended for crossing process boundaries (DTO classes).

So it those classes which:

• All their properties are simple types
• And if they have complex properties, their types themselves are serializable

Tokoloshe

Answer 3

Marking it as [Serializable] (or ISerializable) is necessary for anything using BinaryFormatter, which may well include viewstate under the default configuration. As for good vs bad practice... well, most classes don't need to be serialized, and IMO even when they are, using BinaryFormatter is not always the best choice*. And specifically, marking it as both [Serializable] and [DataContract] will cause an exception IIRC.

*=actually, IMO BinaryFormatter is very rarely a good choice, but I might be biased... and I deliberately don't use viewstate ;p

Metaphor