Why use serialization

Question

I saw a couple of examples with a serializable attribute:

[Serializable()] public class sampleClass { public int Property1{ get; set; } public string Proerty2{ get; set; } public sampleClass() { } public sampleClass(int pr1, int pr2) { pr1 = pr1; Name = pr2.ToString(); } } 

I have never figured out how this works, but from msdn :

Serialization allows the developer to save the state of the object and recreate it as necessary, providing storage of objects, as well as data exchange. Thanks to serialization, a developer can perform actions like sending an object to a remote application using the Web Service, transferring the object from one domain to another, passing the object through the firewall as an XML string, or maintaining security or user information for all applications.

But the problem is that in my code example, I see no reason to use it. Just an object that is used to retrieve data from a database, nothing special. What are some other uses, when to use and when not to use serialization. For example, should I always use serialization because it is more secure? will it go slower this way?

Update: thanks for all the nice answers

Answer 1

Serialization is useful whenever you want to move the presentation of your data to or from a process boundary.

Saving an object to disk is a trivial example that you will see in many textbooks.

Most often, serialization is used to transfer data to and from a web service or to store data in or out of a database.

Answer 2

Several answers explain the reasons why you might want to use serialization in general. You seem to also want to know why a particular class has a [Serializable] attribute, and you wonder why this is possible.

In ASP.NET, the default session state store is InProc , which allows you to store any object as a link and leave it on the heap. This is the most efficient way to store session state, but it only works if you use one workflow or if all session state can be automatically restored if the workflow should change (unlikely). For other state storage modes ( StateServer and SQL Server ), all session state objects must be serializable because the ASP.NET engine first serializes these objects using binary serialization before sending it to the media.

In your case, you can use InProc . One of the reasons is that you still mark all classes that are used in the session state as Serializable and check them so that you may need to change this in the future (for example, to use a web farm). If you are not developing your session state classes, keeping in mind that in the future it will be quite difficult to complete the migration.

In addition, just because you can remove the Serializable attribute, and a program "runs" in one environment does not mean that it will work in another environment. For example, it might work just fine for you on the Visual Studio test web server (which always uses the InProc session state InProc ) and even on the IIS instance for development, but then maybe the production IIS instance is configured to use a different storage mode.

These differences in environment / configuration are not necessarily limited to ASP.NET applications. There are other applications that can run this or even stand-alone applications (it’s easy to build such a configuration environment).

Finally, you can work with a library that can be used by various applications. Some may need to keep the state serialized, while others may not.

Because of these factors, it is often a very good idea, at least when creating a library, to consider labeling simple value classes or state management classes using [Serializable] . Keep in mind that this increases the work for testing these classes, and there are restrictions on what can be serialized (i.e. a class containing a socket link or a link to an open file may not be a good candidate for serialization, since open external resources cannot be serialized) so do not abuse it.

You asked if using [Serializable] would be slower. No, this will not happen. This attribute does not affect performance. However, if the application environment is modified to serialize the object, then yes, performance will be affected. This is a process of serialization and deserialization, which is slower than just storing an object on the heap. [Note that some procedures may be written to search for the Serializable attribute, and then select serialization, but this is rare; this usually looks like ASP.NET and leaves the administrator or user to decide if they want to change the storage environment.]

Answer 3

The MSDN link you provided explains when serialization is useful: for transporting or storing data. Writing to a file is serialization, and serialization is required. T sending the object over the network.

If you just populate an object in one application, possibly from a database, then really: serialization is not a problem. Mapping a class for serialization does not affect security or performance: if you don't need it, don't worry about it.

Note also that [Serializable] mainly refers to BinaryFormatter , but in fact there are many more serializers than that. For example: you can open your object via JSON or XML - both of them require serialization, but do not require [Serializable] .

Answer 4

A simple example: imagine that you have a custom form for storing application settings.

 namespace My.Namespace { [Serializable] public class Settings { public string Setting1 { get; set; } public string Setting2 { get; set; } } } 

Then you can have the xml file as such:

 <?xml version="1.0" encoding="utf-8" ?> <Settings> <Setting1>Foo</Setting1> <Setting2>Bar</Setting2> </Settings> 

Using the XmlSerializer, you can simply serialize and deserialize your settings.

It is also necessary that your figure be Serializable if you want to write it to an ASP.NET ViewState

These are very simple examples, but demonstrate its usefulness.

Answer 5

What are some other uses and when not to use serialization.

Let me give you one practical example. In one of my applications, XML schemas ( XSD files) were provided for the request and response XML . I need to parse the XML request XML , process and save the information back to several tables. Later I need to prepare an XML response XML and send it back to our client.

I used Xsd2Code to generate schema based C# classes. Thus, parsing an XML request XML is simply deserializing the created object of the request class. Then I can access the properties of the object as it appears in the XML file request. When generating the response, the XML file simply serializes from the created object of the response class, which I populate in my code. This way I can work with C # objects, not XML files. Hope this makes sense.

For example, should I always use serialization because it is safer

I do not think that this is related to security.