2011-04-15 14 views

Respuesta

21

Desde .NET 3.5 SP1, ya no tiene que hacer esto.

Si usted no tiene ningún [DataContract] y [DataMember] atributos, la clase DataContractSerializer se comportará como el viejo XmlSerializer: va a serializar todas las propiedades de lectura/escritura pública que se enumeran en la clase.

usted pierde algunas cosas en el proceso de embargo:

  • ya que no tiene [DataMember] atributos, no se puede definir un orden de los campos más - que va a ser serializados en el orden de apariencia

  • no se puede omitir una propiedad pública (ya que eso requeriría [DataMember] en todas las demás propiedades/campos)

  • no se puede definir una propiedad para ser Required (que sería en el atributo [DataMember] de nuevo)

  • tu clase ahora tiene que tener un público, sin parámetros constructor (por lo general no es necesario para contratos de datos)

Leer all about it in detail de Aaron Skonnard en Pluralsight.

+0

+1 - eso es nuevo para mí, y no debería ser así. :) – razlebe

+2

@razlebe: es Microsoft cediendo a las quejas de hordas de programadores perezosos :-) (al menos eso es lo que dice Juval Lowy) –

3

Me encanta la respuesta de marc, pero quiero agregar algo más de información.

DataContractSerializer y DataContractJsonSerializer admiten, además de otros, muchos otros modelos de serialización. Esto incluye IXmlSerializable, Serializable e ISerializable. Se agregó el soporte POCO en .NET 3.5 SP1, pero el soporte para estos otros modelos siempre estuvo presente desde .NET 3

This blog post detalla la extensión del soporte y más importante, la priorización de los diferentes modelos por el serializador (es decir, le dice lo que harían los serializadores basados ​​en DataContract si tiene un tipo decorado con múltiples modelos de serialización)

Por lo tanto, si lee esa publicación de blog, notará que la ayuda de POCO está última en la lista de prioridades. Es el último recurso del serializador, si no hay ningún otro modelo de programación de serialización disponible en el tipo o su padre. Por ejemplo, si el tipo es enumerable de algún tipo, se serializará de acuerdo con traditional collection rules. Si es ISerializable o Serializable, se serializará de acuerdo con sus reglas de serialización.

Otra diferencia importante: durante la deserialización de todos los demás tipos, nunca se llama al constructor predeterminado de cero params. Para los tipos de POCO, siempre se llama! ¡Esto le da un gancho adicional que no tiene tan fácilmente en otros modelos de serialización!