2010-01-12 7 views
5

Acabo de escribir este SerializationHelper clase, pero no puedo creer que sea necesario.¿Realmente necesito escribir este "SerializationHelper"?

using System.IO; 
using System.Xml.Serialization; 

public static class SerializationHelper 
{ 
    public static string Serialize<T>(T obj) 
    { 
     var outStream = new StringWriter(); 
     var ser = new XmlSerializer(typeof(T)); 
     ser.Serialize(outStream, obj); 
     return outStream.ToString(); 
    } 

    public static T Deserialize<T>(string serialized) 
    { 
     var inStream = new StringReader(serialized); 
     var ser = new XmlSerializer(typeof(T)); 
     return (T)ser.Deserialize(inStream); 
    } 
} 

y se usa así:

var serialized = SerializationHelper.Serialize(myObj); 

y:

var myObj = SerializationHelper.Deserialize<MyType>(serialized) 

Me estoy perdiendo algo en la plataforma .NET? ¡Esto no es ciencia de cohetes!

+0

No he visto nada en el marco .NET para suplantar su implementación de Serialize genérica. –

+5

Probablemente se trate de características que comienzan en -100 (parafraseando http://blogs.msdn.com/ericlippert/archive/2009/06/15/making-it-easier.aspx). Los diseñadores BCL no deben haber pensado que la creación de objetos a partir de cadenas xml (y viceversa) merecía todo el trabajo necesario para agregar una función a la API, en particular *, ¡ya que no es ciencia! –

+0

Normalmente, la serialización es una función de T, en lugar de un serializador genérico. Esto se debe a que no siempre es necesario serializar todo de una clase para restaurarlo, por lo que la clase con el conocimiento específico es el lugar mejor informado para realizar esta actividad. – Lazarus

Respuesta

0

Es útil si está haciendo una cantidad real (> 1) de serialización/deserialización dentro de un proyecto. Este fue el caso para mí una vez, así que simplemente puse una clase similar en una biblioteca de Utils, junto con otras funciones reutilizables.

1

En realidad, los bits en el que llamar a la API .NET son los siguientes:

var ser = new XmlSerializer(typeof(T)); 
ser.Serialize(outStream, obj); 

var ser = new XmlSerializer(typeof(T)); 
var obj = (T) ser.Deserialize(inStream); 

El resto del código es su especialización personal. No creo que dos líneas de código sean demasiado para llamar a una API. Siempre puedes condensarlos, p.

(new XmlSerializer(typeof(T))).Serialize(outStream, obj); 

var obj = (T) (new XmlSerializer(typeof(T))).Deserialize(inStream); 

puramente como un aparte, debo señalar que considero almacenamiento de datos XML en variables de cadena como un olor Código. Tan pronto como elimine los datos XML de su forma binaria sin procesar (XDocument, XmlDocument, XPathDocument o cualquier otro tipo de DOM), se encontrará con problemas de codificación. ¿Qué ocurre si un desarrollador serializa un objeto en una cadena con codificación X y luego escribe la cadena en un archivo de disco con codificación Y? No muy seguro. Además, si la codificación X no es UTF-16, ¿cómo representarías los datos en una cadena .NET?

+0

Le falta un lanzamiento a T en su última línea. .. de lo contrario, obtengo un "objeto". Y está dejando fuera de su "condensar" el hecho de que tengo que mencionar el nombre de tipo explícitamente mucho, lo que evita mi solución – JoelFan

+0

Bien manchado, he editado el texto. –

+0

Joel, estoy de acuerdo, es mucha mecanografía. Tienes que preguntarte, ¿en qué momento escribir un método de utilidad para ahorrarte tipear se convierte en una pérdida de tiempo? Si sus métodos realmente le ahorran tiempo y hacen que su código sea más legible, entonces es genial, guárdelo. Todo lo que digo es que los diseñadores de la API 'XmlSerializer' no estaban de acuerdo con usted. –

Cuestiones relacionadas