Является ли интерфейс ISerializable необходимым, если вы не выполняете какую-либо пользовательскую сериализацию/десериализацию

Я рассматриваю класс в решении, которое реализует интерфейс ISerializable. Он имеет метод GetObjectData для сериализации, как того требует интерфейс. Здесь нет никакой специальной сериализации, она просто заполняет объект SerializationInfo именами свойств класса и их значений.

[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);
    }
}

Из документации, которую я прочитал до сих пор, насколько я понимаю, это то, что произойдет в любом случае классом, отмеченным атрибутом [Serializable], и, как вы видите, у класса нет конструктора десериализации, поэтому я и смотрю на это с самого начала. Из того, что я могу сказать, вместо того, чтобы добавлять конструктор десериализации в класс, классу действительно не нужно реализовывать интерфейс ISerializable в первую очередь. Это правильно?

Ответы

Ответ 1

Это довольно бессмысленно.

Это может быть оправдано, если он когда-то реализовал ISerializable по лучшей причине, а изменения в реализации означали, что он уже не так полезен. Это может быть потрясающее изменение, чтобы прекратить его реализацию.

Если бы они реализовали его с явной реализацией (void ISerializable.GetObjectData(SerializationInfo info, StreamingContext context), а не public void GetObjectData(SerializationInfo info, StreamingContext context)) и имели конструктор, который принял SerializationInfo и StreamingContext private, тогда это будет менее разрушительное изменение - по-прежнему технически но гораздо менее вероятно, чтобы фактически нарушить любое реальное использование. Это само по себе является причиной того, что этот конструктор является частным.

Он должен быть хотя бы protected, если класс не запечатан, и производные классы должны использовать его, если они также должны быть сериализованы. В этом случае он полностью изменится, чтобы перестать использовать его, так как все производные классы будут затем разбиты.

Это также изменило бы изменения, если бы вы не реализовали его, а затем начали делать это и получили от него классы. Это может быть оправданием для предпосылки возможности, хотя, честно говоря, я бы увидел это как серьезный провал принципа YAGNI, если не было очень веских оснований подозревать, что это станет полезным. (Как правило, если вы собираетесь добавить что-то, что сделало бы это необходимым, вы могли бы обернуть все функции, которые требуются в другом классе, реализовать его на этом и иметь член этого типа, поэтому существующий класс все равно может быть сериализован без него).

Изменить: "must" выше - это "must" из "вы должны это сделать или есть плохие последствия", а не "must" из "вы должны это сделать или не будете компилировать". Конечно, первые хуже, чем последние, потому что иногда вы не можете их сделать.

Ответ 2

классу действительно не нужно реализовывать интерфейс ISerializable в первую очередь. Это правильно?

Правильно. Реализация ISerializable - это когда вам нужно что-то делать, кроме поведения сериализации по умолчанию. Атрибут [Serializable] должен быть достаточным.

Ответ 3

Вы могли бы также всегда внедрять ISerializable. Да, это может быть много набрав, если у вас много объектов, но десериализатор сломается, если вы позже его представите. Я думаю, что лучше для версий объектов вместо написания новых и сохранения старых.

Ответ 4

Реализация Iserializable дает улучшение производительности, потому что нет необходимости использовать отражение для сериализации объекта

Ответ 5

Требуется конструктор подписи (информация SerializationInfo, контекст StreamingContext). для времени десериализации.

Ответ 6

Я вижу, реализация ISerializable не требуется для этого класса. Или вы должны добавить конструктор с сигнатурой (информация SerializationInfo, контекст StreamingContext): protected PersonName (SerializationInfo info, StreamingContext context){ this.NamePrefix = info.GetString("NamePrefix"); this.SurName = info.GetString("SurName"); this.GivenName = info.GetString("GivenName"); }