DataContractSerializer no llama a mi constructor?

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

Tome 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 deserializo un objeto de esa clase, el punto de inflexión no se golpea. No tengo ni idea de cómo es posible, ya que es el único constructor de este objeto.

Supuse que tal vez el comstackdor generó un constructor adicional debido al atributo DataContract , pero no pude encontrarlo a través de la reflexión …

Entonces, lo que me gustaría saber es esto: ¿cómo se podría crear una instancia de mi clase sin llamar al constructor?

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

DataContractSerializer (como BinaryFormatter ) no usa 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 llamadas si es necesario) lo inicializará por completo.

Hay algunos escenarios que no serían posibles sin este comportamiento. Piensa 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 lo mencionó, el atributo [OnDeserializing] permite mantener sincronizados los datos no serializados.