Serializable Attribute And Implement ISerializable
5455 ワード
Serialization is the process of saving an object onto a storage medium (such as a file, or a memory buffer) or transmiting it across a network connection link in binary form. this two ways is involved with binary serialization . have nothing to do with xml. (Except for using SoapFormat which result in xml data.)for example . you can see the ISerializable.GetObjectData is not called in XML serialization process. if you want to do that.
The .NET Framework provides an easy-to-use serialization mechanism by using the [Serializable] attribute. If so why do we need the ISerializable interface? Lets compare to see the differences…
Marking your class, struct, delegate or enum as [Serializable] indicates that this class can be serialized. The .Net runtime uses Reflection at runtime, and by default all public and private fields are serialized , unless you apply the NonSerializedAttribute .
Implementing the ISerializable Interface allows the object to control the serialization process. we’ll soon see what that means, but it’s important to notice that you must also mark the class with the SerializableAttribute. Implementing the interface means, implementing two methods: GetObjectData to populate fields into the SerializationInfo , and another constructor which is called during deserialization to restore object state from the SerializationInfo.
Now Lets try to compare them by a few aspects
Inheritance - in both ways, derived classes must be marked with the SerializableAttribute (for the 1st choice, that’s all that needs to be done). However, if you implement the interface, the derived class would probably need to implement it too (don’t forget to also call the base class implementation). Another thing to remember is implementing the special constructor. It cannot be enforced by the compiler, so if you forget it- you’ll get a runtime exception “The constructor to deserialize an object of type … was not found.”!
Control - obviously implementing the interface give you full control. However if all you want to do is to leave some fields out of the serialization, just use the NonSerializedAttribute attribute. If you need more control, like performing some initialization code or validating the read values, use the ISerializable interface.
Performance - Option 1 uses Reflection. We know this is not the fastest way, however if your class contains only few primitive types the penalty is not so big. If you have more complicated collections you might consider serializing them yourself.
Versioning - If you add, remove or rename class fields, you will not be able to desirialize old saved object into a new one. to support this you will have to implement ISerializable.
In Summary, I am sure there are more aspects of Serialization which are not covered here, but my conclusion and also microsoft’s advice is - use the SerializableAttribute unless your have a good reason to implement the ISerializable Interface.
see also :
http://www.cnblogs.com/qqflying/archive/2008/01/13/1037262.html
The .NET Framework provides an easy-to-use serialization mechanism by using the [Serializable] attribute. If so why do we need the ISerializable interface? Lets compare to see the differences…
1. The Serializable Attribute
Marking your class, struct, delegate or enum as [Serializable] indicates that this class can be serialized. The .Net runtime uses Reflection at runtime, and by default all public and private fields are serialized , unless you apply the NonSerializedAttribute .
[Serializable]
class MyClass
{
public string FirstName { get; set; }
}2. The ISerializable Interface
Implementing the ISerializable Interface allows the object to control the serialization process. we’ll soon see what that means, but it’s important to notice that you must also mark the class with the SerializableAttribute. Implementing the interface means, implementing two methods: GetObjectData to populate fields into the SerializationInfo , and another constructor which is called during deserialization to restore object state from the SerializationInfo.
[Serializable]
class MyClass : ISerializable
{
public string FirstName { get; set; }
public MyClass() { }
public void GetObjectData(SerializationInfo info, StreamingContext context)
{
info.AddValue("FirstName", FirstName);//Will be Called If you use SoapFormatter
}
protected MyClass(SerializationInfo info, StreamingContext context)
{
FirstName = info.GetString("FirstName");
}
}Now Lets try to compare them by a few aspects
Inheritance - in both ways, derived classes must be marked with the SerializableAttribute (for the 1st choice, that’s all that needs to be done). However, if you implement the interface, the derived class would probably need to implement it too (don’t forget to also call the base class implementation). Another thing to remember is implementing the special constructor. It cannot be enforced by the compiler, so if you forget it- you’ll get a runtime exception “The constructor to deserialize an object of type … was not found.”!
Control - obviously implementing the interface give you full control. However if all you want to do is to leave some fields out of the serialization, just use the NonSerializedAttribute attribute. If you need more control, like performing some initialization code or validating the read values, use the ISerializable interface.
Performance - Option 1 uses Reflection. We know this is not the fastest way, however if your class contains only few primitive types the penalty is not so big. If you have more complicated collections you might consider serializing them yourself.
Versioning - If you add, remove or rename class fields, you will not be able to desirialize old saved object into a new one. to support this you will have to implement ISerializable.
In Summary, I am sure there are more aspects of Serialization which are not covered here, but my conclusion and also microsoft’s advice is - use the SerializableAttribute unless your have a good reason to implement the ISerializable Interface.
see also :
http://www.cnblogs.com/qqflying/archive/2008/01/13/1037262.html