L'implémentation de l'interface ISerializable est nécessaire lorsque vous ne mettez en œuvre aucune sérialisation / désérialisation personnalisée

Je suis à la recherche à une classe dans une solution qui implémente l' ISerializable interface. Il a un GetObjectData méthode pour la sérialisation comme requis par l'interface. Il n'y a pas toute la sérialisation personnalisée qui se passe ici, c'est tout simplement le remplissage de la SerializationInfo objet avec les noms des propriétés de la classe et de leurs valeurs.

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

À partir de la documentation que j'ai lu jusqu'à présent, ce que je comprends, c'est ce qui se passera de toute façon par la classe d'être marqué avec le [Serializable] attribut, et comme vous pouvez le voir, la classe n'a pas une désérialisation constructeur, c'est pourquoi je suis à la recherche pour commencer. De ce que je peux dire, plutôt que d'avoir besoin d'ajouter de la désérialisation constructeur de la classe, la classe n'a pas vraiment besoin pour mettre en œuvre les ISerializable interface en premier lieu. Est-ce exact?

source d'informationauteur jaywon

  1. 8

    C'est assez inutile.

    Il pourrait être justifiée si elle avait une fois mis en œuvre ISerializable pour une bonne raison, et la mise en œuvre des changements signifiait qu'il n'était plus utile. Il pourrait être une modification de rupture pour arrêter de la mettre en œuvre.

    Si ils avaient mis en oeuvre avec une mise en œuvre explicite (void ISerializable.GetObjectData(SerializationInfo info, StreamingContext context) plutôt que public void GetObjectData(SerializationInfo info, StreamingContext context) et avait le constructeur qui a pris SerializationInfo et StreamingContext privé, alors qu'il serait moins dommageable de changement encore, techniquement, d'une modification de rupture, mais beaucoup moins susceptibles de casser tout réel utilise. En soi c'est une raison pour avoir ce constructeur privé.

    Il doit bien être d'au moins protected si la classe n'est pas scellée, et les classes dérivées doivent utiliser si ils sont aussi serialisable. Dans ce cas, il est absolument va être une modification de rupture de cesser de l'utiliser comme toutes les classes dérivées serait alors rompu.

    Il serait même modification de rupture si vous n'avez pas la mettre en œuvre, puis a commencé à le faire, et avait des classes dérivées. Cela pourrait être une justification pour préjuger de la possibilité, mais pour être honnête, je préfère voir ça comme un échec majeur de la YAGNI principe sauf s'il y a une très très bonne raison de soupçonner qu'il allait devenir utile. (En général, si vous allez à ajouter quelque chose qui rendrait nécessaire, vous pouvez rassembler quelles que soient les fonctionnalités nécessaires dans une autre classe, à la mettre en œuvre, et qui ont un membre de ce type, de sorte que la classe existante peut encore être sérialisé sans elle).

    Edit: Le "doit" ci-dessus est le "must" de "vous devez faire ceci ou il y a de mauvaises conséquences" plutôt que le "must" de "vous devez faire ceci ou de ne pas compiler". Bien sûr, les premiers sont pire que la dernière parce que vous pouvez parfois ne parviennent pas à les faire.

  2. 12

    la classe n'a pas vraiment besoin de mettre en œuvre l'interface ISerializable en premier lieu. Est-ce exact?

    Correcte. La mise en œuvre de ISerializable est quand vous avez besoin de faire autre chose que la sérialisation par défaut de comportement. Le [Serializable] attribut devrait être suffisant.

  3. 2

    Vous pouvez ainsi toujours implment ISerializable. Oui, ça peut être beaucoup de saisie si vous avez beaucoup d'objets, mais la deserializer va casser si par la suite vous la présenter. Je pense que c'est mieux pour la gestion des versions des objets à la place de l'écriture de nouvelles et de garder les anciens.

  4. 1

    La mise en œuvre de Iserializable donne une amélioration de la performance car il n'est pas nécessaire d'utiliser la réflexion pour sérialiser l'objet

  5. 0

    Une signature constructeur (SerializationInfo de l'information, StreamingContext contexte) est nécessaire. pour la désérialisation temps.

  6. 0

    Je vois, la mise en œuvre de ISerializable n'est pas nécessaire pour cette classe.ou vous devez ajouter un constructeur avec signature (SerializationInfo de l'information, StreamingContext contexte) :
    protected PersonName (SerializationInfo info, StreamingContext context){
    this.NamePrefix = info.GetString("NamePrefix");
    this.SurName = info.GetString("SurName");
    this.GivenName = info.GetString("GivenName");
    }