Avantages de [NonSerialized] lorsque [Serializable] n'est pas utilisé

Question

Je suis à la recherche par le biais du code existant dans un projet sur lequel je travaille, et je l'ai trouvé une classe qui est mis en œuvre comme:

public class ThingOne
{
    private int A;

    private int B;

    [NonSerialized]
    private System.Timers.Timer timer1;
}

ne doit pas ressembler davantage à ce sujet?

[Serializable]
public class ThingOne
{
    private int A;

    private int B;

    [NonSerialized]
    private System.Timers.Timer timer1;
}

Ou est-il un avantage supplémentaire à ajouter [NonSerialized] même lorsque la classe elle-même est pas Serializable?

Answer 1

NonSerialized aura aucun effet lorsque Serializable n'est pas utilisé. Par défaut, les classes et leurs membres ne sont pas sérialisable.

Le seul avantage de déclarer quelque chose NonSerialized lorsque la classe ne sérialisé est dans les circonstances que la classe est héritée par un objet sérialisé, et le membre hérité sera non sérialisable.

MSDN :

  

attribut 'NonSerialized' ne sera pas   affecter ce membre parce que son   classe contenant est pas exposé comme   'Serializable'.

     

Par défaut, les classes et leurs membres sont non sérialisable. L'attribut NonSerializedAttribute est nécessaire que si un membre d'une classe sérialisable ne doit pas être sérialisé.

Answer 2

  

Ou est-il un avantage supplémentaire à ajouter [NonSerialized] même lorsque la classe elle-même est pas Serializable?

La classe n'est pas scellé, donc une autre classe pourrait hériter de cet objet. Cette classe pourrait être marqué comme sérialisable, puis l'attribut NotSerializable entrerait en jeu. (Bien que pas indiqué pour les membres privés).

Souvenez-vous que vous pouvez vérifier les attributs par la réflexion aussi. Il ne peut pas être utilisé par le moteur d'exécution pour vérifier ce qui doit et ne doit pas être publié en feuilleton, il pourrait être utilisé comme marqueur pour quelque chose d'autre dans la négociation du programme avec une sorte de sérialisation personnalisé (je ne dis pas que ce soit une bonne idée le moins).

Answer 3

Je peux penser à deux raisons:

1. Il pourrait être vital que le champ ne soit pas publié en feuilleton. Par conséquent, si à l'avenir la classe est faite serialisable, ce ne sera pas introduire un bug, problème de l'inefficacité ou de la sécurité, parce que sans elle marque la serialisable de classe le fera également pour le champ.

2. Ils pourraient faire une sorte d'utilisation personnalisée de l'attribut

Dans le cas 2, il sera clair d'ailleurs dans le code que c'est ce qui se passe. Le numéro 1 est une bonne pratique cependant.

Cas n ° 1 est une bonne pratique, il peut être utile d'équilibrage YAGNI ( « yagni » - ne pas faire le travail « dans le cas où il est nécessaire plus tard ») avec l'examen « d'accord, mais si je besoin plus tard, ce sera une catastrophe si quelqu'un manque que ce champ est une exception.

Ainsi, alors qu'il n'a pas d'effet ici, il est sans aucun doute une bonne pratique pour les scénarios où il commence à avoir un effet.

Edit: Une autre possibilité est qu'il est CRUFT d'une version précédente où il était en effet serialisable ou l'auteur était dans deux esprits à l'époque et il n'a jamais été entièrement « fini » (code de travail est toujours entièrement terminé?). Tout simplement parce que quelque chose est dans le code, ne signifie pas qu'il était censé être de cette façon. Pourtant, s'il est vraiment important que quelque chose ne soit pas publié en feuilleton, je dis toujours qu'il est bon de marquer ce pour la raison donnée ci-dessus.

Answer 4

états MSDN SerializeAttribute que « Appliquer l'attribut SerializableAttribute à un type pour indiquer que les cas de ce type peuvent être sérialisés. » cela implique que sans elle, la classe ne peut pas être sérialisé. Je crois avoir essayé cela et le serialize lancera une exception si elle est tentée sur un type non sérialisable.

Answer 5

Je suis d'accord avec Greg, MSDN il dit d'une manière similaire, citant des références est une bonne idée ..

« Par défaut, les classes et leurs membres sont non sérialisable. L'attribut NonSerializedAttribute est nécessaire que si un membre d'une classe sérialisable ne doit pas être publié en feuilleton. »

http://msdn.microsoft.com/ fr-fr / bibliothèque / dwys85sk (VS.80) .aspx