Is implementing ISerializable interface necessary when not implementing any custom serialization/deserialization

Question

I am looking at a class in a solution that implements the ISerializable interface. It has a GetObjectData method for serialization as required by the interface. There is not any custom serialization happening here, it is simply populating the SerializationInfo object with the names of the properties of the class and their values.

[Serializable]
public class PersonName :ISerializable
{
    [DataMember]
    public string NamePrefix { get; set; }
    [DataMember]
    public string GivenName { get; set; }
    [DataMember]
    public string SurName { get; set; }

    public PersonName(string givenName, string surName, string namePrefix)
    {
        GivenName = givenName;
        SurName = surName;
        NamePrefix = namePrefix;
    }

    public PersonName()
    {
    }

    #region ISerializable Members

    public void GetObjectData(SerializationInfo info, StreamingContext context)
    {
        info.AddValue("NamePrefix",NamePrefix);
        info.AddValue("GivenName",GivenName);
        info.AddValue("SurName",SurName);
    }
}

From the documentation I've read so far, as I understand it, this is what would happen anyway by the class being marked with the [Serializable] attribute, and as you can see the class does not have a deserialization constructor, which is why I'm looking at it to begin with. From what I can tell, rather than needing to add the deserialization constructor to the class, the class really doesn't need to implement the ISerializable interface in the first place. Is that correct?

Solution 1

It's pretty pointless.

It could be justified if it had once implemented ISerializable for a better reason, and implementation changes meant that it was no longer as useful. It could be a breaking change to stop implementing it.

If they'd implemented it with an explicit implementation (void ISerializable.GetObjectData(SerializationInfo info, StreamingContext context) rather than public void GetObjectData(SerializationInfo info, StreamingContext context) and had the constructor that took SerializationInfo and StreamingContext private, then it'd be a less damaging change - still technically a breaking change but much less likely to actually break any real uses. This in itself is a reason for having that constructor private.

It must though be at least protected if the class isn't sealed, and derived classes must use it if they are to also be serialisable. In this case it's totally going to be a breaking change to stop using it as all derived classes would then be broken.

It would likewise be breaking change if you didn't implement it, and then started doing so, and had classes derived from it. This could be a justification for pre-empting the possibility, though to be honest I'd see that as a major failure of the YAGNI principle unless there was a very very good reason to suspect it would become useful. (Generally if you were going to add something that would make it necessary you could wrap whatever features required it in another class, implement it on that, and have a member of that type, so the existing class can still be serialised without it).

Edit: The "must" above is the "must" of "you must do this or there are bad implications" rather than the "must" of "you must do this or it won't compile". Of course, the former are worse than the latter because you can sometimes fail to do them.

Solution 2

the class really doesn't need to implement the ISerializable interface in the first place. Is that correct?

Correct. Implementing ISerializable is when you need to do something other than the default serialization behavior. The [Serializable] attribute should be enough.

Solution 3

You might as well always implment ISerializable. Yeah, it can be a lot of typing if you have a lot of objects, but the deserializer will break if you later introduce it. I think it is better for versioning objects instead of writing new ones and keeping old ones.

Solution 4

Implementing Iserializable gives a performance improvement because there is no need to use reflection to serialize the object

View more solutions

Comments

[user1703401]

Right. The way to tell is by not being to come up with anything unusual in the GetObjectData() method. Or in other words, needing something else than just the info argument to initialize the object.

[Roy Oliver]

Actually, I was stuck in the frame of mind for using Aggregate Roots in DDD. Basically, if your object inherits from the another serializable object, make sure both implement ISerializable and call the base class GetObjectData(info, context) method and its ctor(info, context). Otherwise, all you need is [Serializable] the attribute.