Beneficios de la [NonSerialized] cuando [Serializable] no se utiliza

Question

estoy mirando a través de un código existente en un proyecto en el que estoy trabajando, y me encontré con una clase que se implementa como:

public class ThingOne 
{ 
    private int A; 

    private int B; 

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

no deben ¿Se parece más a esto?

[Serializable] 
public class ThingOne 
{ 
    private int A; 

    private int B; 

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

¿O hay algún beneficio adicional al agregar [No serializado] incluso cuando la clase en sí no es Serializable?

Answer 1

NonSerialized no tendrá efecto cuando no se pueda serializar. Por defecto, las clases y sus miembros no son serializables.

La única ventaja de declarar algo no serializado cuando la clase no está serializada es bajo las circunstancias que la clase es heredada por un objeto serializado, y luego el miembro heredado no será serializable.

De MSDN:

atributo 'NonSerialized' no afectará a este miembro porque su clase que contiene no se expone como 'Serializable'.

De forma predeterminada, las clases y sus miembros no son serializables. El atributo NonSerializedAttribute solo es necesario si un miembro de una clase serializable no debe ser serializado.

Answer 2

O hay algún beneficio adicional a la adición de [NonSerialized] incluso cuando la clase en sí no es Serializable?

La clase no está sellada, por lo que otra clase podría heredar de ese objeto. Esa clase podría marcarse como Serializable y, a continuación, entraría en juego el atributo NotSerializable. (aunque como se señaló no para miembros privados).

Recuerde que también puede verificar los atributos por reflexión. El tiempo de ejecución no puede usarlo para verificar lo que debe y no debe ser serializado, podría usarse como marcador para otra cosa en el programa que trata sobre algún tipo de serialización personalizada (no digo que sea una buena idea en El menos).

Answer 3

Estoy de acuerdo con Greg, MSDN indica que de una manera similar, citando referencias es una buena idea ..

"Por defecto, las clases y sus miembros son no serializable. El atributo NonSerializedAttribute sólo es necesario si una miembro de una clase serializable no debe serializarse ".

http://msdn.microsoft.com/en-us/library/dwys85sk(VS.80).aspx

Answer 4

MSDN SerializeAttribute establece que "Aplicar el atributo SerializableAttribute a un tipo para indicar que los casos de este tipo se pueden serializar". Esto implica que, sin ella, la clase no puede ser serializado. Creo que lo he intentado y serializar arrojará una excepción si se intenta en un tipo no serializable.

Answer 5

me ocurren dos razones:

1. Podría ser de vital importancia que el campo no es de serie.Por lo tanto, si en el futuro la clase se hace serializable, esto no introducirá un error, ineficiencia o problema de seguridad, ya que sin ella, la clase serializable también lo hará para el campo.

2. que podrían estar haciendo algún tipo de uso a medida del atributo

En el caso 2 que va a ser claro a partir del código que esto es lo que está pasando en otros lugares. Sin embargo, el número 1 es una buena práctica.

Caso 1 es una buena práctica, puede valer la pena equilibrar YAGNI ("No vas a necesitarlo" - no hacer el trabajo "en caso de que sea necesario más tarde") con la consideración "bien, pero si lo necesito más tarde" , va a ser un desastre si alguien falta que este campo es una excepción.

Así que, aunque no tiene ningún efecto aquí, es definitivamente una buena práctica para los escenarios en los que comienza a tener un efecto.

Editar: Otra posibilidad es que se trata de una versión anterior donde era de hecho serializable o el autor estaba en dos mentes en ese momento y nunca fue completamente "terminado" (¿el código de trabajo está completamente terminado?) Solo porque algo es en el código, doesn No significa que se suponía que fuera de esa manera. Aún así, si es realmente importante que algo no se serialice, sigo diciendo que es una buena práctica marcar esto por la razón dada anteriormente.