Effective C # Principle 25 enables serialization of your type

The persistence of an object is a core function of a type. This is one of the basic elements that no one will notice until you ignore its support. If your type does not properly support serialization, you will add a lot of work to developers who make your Class A base class or a member. When your type does not support serialization, they have to work around this to add their own functionality to implement this standard. For developers who cannot access private members of a class, it is not possible to properly implement the serialization of your type. If your type does not support serialization, it is difficult or impossible for your users to want to implement it.

Instead, add serialization to your actual type. This is useful for those that do not host UI elements, Windows, or types of forms. There is no reason to feel that there is extra work. NET serialization is so simple that you don't have an arbitrary excuse to say you don't support it. In most cases, adding the serializable attribute is sufficient:

[Serializable]
public class MyType
{
　private string _label;
　private int _value;
}

Adding only one serializable attribute is enough to serialize it because its members are serializable: string and int are. NET serialization support. It is important to add serialization support to a type, whether or not it is possible, because it is obvious when you add another class as a member of a new class:

[Serializable]
public class MyType
{
　private string　　　_label;
　private int　 　　　 _value;
　private OtherClass　_object;
}

The serializable feature here is only valid if the Otherclass also supports serialization. If Otherclass does not support serialization, you will get a run-time error when serializing MyType because the Otherclass object is also inside. This is simply because the internal structure of the otherclass is not clear, making serialization impossible.

. NET serialization is to save all the member variables in the class to the output stream. Other than that. NET serialization also supports any object graph: Even if you have a circular reference on your object, the serialize and deserialize methods will only be read and stored once for your actual object. When some of the Web objects are deserialized,. NET serialization framework can also create references to these Web objects. Any web-related objects you create, you can save them correctly after the object graph is serialized. The last place to note is that the Serializable feature supports both binary and SOAP serialization. All of the techniques in this principle support both serialization formats. Remember, however, that it is only successful if all types of object graphs support serialization. That's why it's important to have all types support serialization. Once you've missed a class, you've opened a backdoor to the object graph, so that it becomes more difficult for anyone using this class to serialize the object graph. Before long, they will find they have to write their own serialization code.

Adding the serializable feature is one of the simplest techniques to support the serialization of objects. But the simplest solution is not always the right one. Sometimes you do not want to serialize all the members of an object: Some members may exist only in the cache of long-term operations, and some objects may occupy some run-time resources that can only exist in memory. You can also use features to control these problems. Add the NonSerialized attribute to any data member that you do not want it to serialize. This marks them as not having to be serialized:

Serializable]
public class MyType
{
　private string _label;
　[NonSerialized]
　 private int _cachedValue;
　private OtherClass　_object;
}