Serializable objects Vs Non Serializable objects

Question

Hi Everyone,

what is the differnce Serializable objects vs non serialivable objects, And what makes an object serialiable? And What does serializable objects have to do with xml?

Thanks

Answer 1

Objects that are serializable can be "broken apart", transmitted across a variety of channels and "reconstructed" at the end of the receiving channel which may be an entirely other location in the exact state it was "broken apart" in. You may have heard xml mentioned in the course of talk about serialization because xml provides a mechanism for this.

Consider the following object:

Person p = new Person();
p.Age = 33;
p.Name = "Magni";

If you wanted to save this object in its current state - you could effectively represent this as :

<Person>
    <Name>Magni</Name>
    <Age>33</Age>
</Person>

This XML can then be sent across the wire and the originating Person object can be reconstructed or consumed by another entity or service in the event of different platforms for use.

This is a 30000ft view, serialization often gets complicated, but I tried to answer your question in its broadest sense.

Answer 2

what is the differnce Serializable objects vs non serialivable objects

A serializable object can be converted into some other representation such as text in order to be easily transmitted across process boundaries while a non-serializable object cannot.

And what makes an object serialiable

In .NET depending on the serializer you decide to use, the object needs to correspond to certain requirements. For example if you use the BinaryFormatter your object needs to be decorated with the [Serializable] attribute.

And What does serializable objects have to do with xml

An object could be serialized into XML. In .NET this could be achieved for example with the XmlSerializer class but also with the DataContractSerializer.

Answer 3

The issue is almost never whether or not you can serialize an object. The real problem is often: can you reconstruct a usable and verbatim copy of the object when you de-serialize it.

A good example is a Windows Forms control. A control cannot exist without a parent, say the form on which it is hosted. De-serializing a control leaves you with a control without a parent, you have to serialize the entire object graph to make it meaningful. Then, there are properties that have a runtime value that won't reproduce when you de-serialize. The Handle property for example. Windows won't reproduce the same handle. Or whether or not the short-cut key indicator is underlined (press the Alt key). That critically depends on the entire state of the program. Accordingly, Control does not have the [Serializable] attribute.

Answer 4

The answers here are correct, but attack the concept from a different angle, and hopefully increase your understanding, I propose the following:

Think of the word 'serializable' to mean 'convertable'. So when a class is marked as serializable, then it's convertable to whatever type of representation you're looking for. A serializer (ie. BinaryFormatter or XmlSerializer) can be thought of as a 'converter'.

With that, so to speak, you would use a converter (serializer) to convert something that is convertable (serializable). The class itself doesn't change, but it does add functionality to the class.

Examples of why:

• A common usage is to convert an object to a binary representation (serializing using a binary formatter) if you wanted to easily write it to disk or send it to another application over a socket.
• Another common usage is to convert an object to an xml representation (as seen in RandomNoob's answer) if you wanted to send it to a webservice.

There's some caveats to consider when serializing (for instance, you generally don't want to serialize events in .NET and would so mark them with the [field: non-serialized] attribute), so a bit more research is necessary in that respect, but conceptually, try to think of it as converting an object for storage or transmission.