¿DataContractSerializer no llama a mi constructor?

Question

Me acabo de dar cuenta de algo loco, que asumí que era completamente imposible: al deserializar un objeto, el DataContractSerializer no llama al constructor!

tomar esta clase, por ejemplo:

[DataContract] 
public class Book 
{ 
    public Book() 
    { // breakpoint here 
    } 

    [DataMember(Order = 0)] 
    public string Title { get; set; } 
    [DataMember(Order = 1)] 
    public string Author { get; set; } 
    [DataMember(Order = 2)] 
    public string Summary { get; set; } 
} 

Cuando deserializar un objeto de esa clase, el punto de interrupción no se ve afectado. No tengo ni idea de cómo es posible, ya que es el único constructor de este objeto.

supuse que tal vez un constructor adicional fue generada por el compilador a causa del atributo DataContract, pero no pude encontrar a través de la reflexión ...

Por lo tanto, lo que me gustaría saber es lo siguiente: ¿cómo podría crearse una instancia de mi clase sin llamar al constructor?

NOTA: Sé que puedo utilizar el atributo OnDeserializing para inicializar mi objeto cuando comienza la deserialización, este no es el tema de mi pregunta.

Answer 1

DataContractSerializer (como BinaryFormatter) No utiliza ningún constructor. Crea el objeto como memoria vacía.

Por ejemplo:

Type type = typeof(Customer); 
    object obj = System.Runtime.Serialization. 
     FormatterServices.GetUninitializedObject(type); 

La suposición es que el proceso de deserialización (o devoluciones de llamada si es necesario) se inicializará completamente.

Answer 2

Hay algunos escenarios que no serían posibles sin este comportamiento. Piense en lo siguiente:

1) Tiene un objeto que tiene un constructor que establece la nueva instancia en un estado "inicializado". A continuación, se invocan algunos métodos en esa instancia, que lo llevan a un estado "procesado". No desea crear nuevos objetos que tengan el estado "procesado", pero aún desea de serializar/deserializar la instancia.

2) Creó una clase con un constructor privado y algunas propiedades estáticas para controlar un pequeño conjunto de parámetros de constructor permitidos. Ahora puedes serializarlos/deserializarlos.

XmlSerializer tiene el comportamiento esperado. He tenido algunos problemas con XmlSerializer porque NECESITA un constructor predeterminado. Relacionado con eso, a veces tiene sentido tener instaladores de propiedad privada. Pero el XmlSerializer también necesita getter público y setter en propiedades para serializar/deserializar.

Pienso en el comportamiento de DataContractSerializer/BinaryFormatter, como suspender el estado de una instancia durante la serialización y reanudar durante la deserialización. En otras palabras, las instancias no son "construidas" sino "restauradas" a un estado anterior.

Como ya se ha mencionado, el atributo [OnDeserializing] permite mantener sincronizados los datos no serializados.