¿Por qué utilizar la serialización

Question

que he visto par de ejemplos con el atributo serializable como esto:

[Serializable()] 
      public class sampleClass 
      { 
       public int Property1{ get; set; } 
       public string Proerty2{ get; set; } 

       public sampleClass() { } 
       public sampleClass(int pr1, int pr2) 
       { 
        pr1 = pr1; 
        Name = pr2.ToString(); 
       } 
      } 

nunca tuvo una buena comprensión de la comprensión de cómo funciona esto, pero a partir de msdn:

serialización permite al desarrollador guardar el estado de un objeto y recrearlo según sea necesario, proporcionando el almacenamiento de objetos así como el intercambio de datos . Mediante la serialización, un desarrollador puede realizar acciones , como enviar el objeto a una aplicación remota mediante un servicio web , pasar un objeto de un dominio a otro, pasar un objeto a través de un cortafuegos como cadena XML o mantener la seguridad o información específica del usuario en todas las aplicaciones.

Pero el problema es que en mi ejemplo de código no veo uso. Solo un objeto que se usa para recuperar datos de la base de datos, nada especial. ¿Cuáles son algunos otros usos sobre cuándo usar y cuándo no usar la serialización? Por ejemplo, ¿debería usar siempre serializzation porque es más seguro? ¿Va a ser más lento de esta manera?

Actualización: Gracias por todas las respuestas agradables

Answer 1

serialización es útil en cualquier momento que desee mover una representación de los datos dentro o fuera de su límite de proceso.

Guardar un objeto en el disco es un ejemplo trivial que verá en muchos tutoriales.

Más comúnmente, la serialización se usa para transferir datos hacia y desde un servicio web, o para conservar datos hacia o desde una base de datos.

Answer 2

La cita de MSDN que proporciona explica cuando la serialización es útil: para transportar o almacenar datos. Escribir en un archivo es serialización, y se requiere serialización para enviar un objeto a través de una red.

Si solo está completando el objeto en una sola aplicación, tal vez desde una base de datos, de hecho: la serialización no es una preocupación en absoluto. La generación de imágenes de una clase para la serialización no tiene impacto en la seguridad o el rendimiento: si no lo necesita, no se preocupe.

Tenga en cuenta también que [Serializable] se refiere principalmente a BinaryFormatter, pero en realidad hay muchos más serializadores que eso. Por ejemplo: es posible que desee exponer su objeto mediante JSON o XML; ambos requieren serialización, pero ninguno requiere [Serializable].

Answer 3

Ejemplo simple: imagine que tiene una forma personalizada para almacenar la configuración de la aplicación.

namespace My.Namespace 
{ 
    [Serializable] 
    public class Settings 
    { 
     public string Setting1 { get; set; } 

     public string Setting2 { get; set; } 
    } 
} 

A continuación, podría tener un archivo de un archivo XML como por ejemplo:

<?xml version="1.0" encoding="utf-8" ?> 
<Settings> 
    <Setting1>Foo</Setting1> 
    <Setting2>Bar</Setting2> 
</Settings> 

Usando XmlSerializer simplemente podría serializar y deserializar los ajustes.

También es necesario que su forma sea Serializable si desea rellenarla en ASP.ViewState NET

Estos son ejemplos muy básicos, pero demuestran su utilidad

Answer 4

Varias respuestas han cubierto las razones de por qué es posible que desee utilizar la serialización en general. Parece que también quiere saber por qué una clase específica tiene el atributo [Serializable] y se pregunta por qué se pudo haber hecho.

Con ASP.NET, el almacenamiento de estado de sesión predeterminado es InProc, que le permite almacenar cualquier objeto como referencia y dejarlo en el montón. Esta es la mejor forma de almacenar el estado de la sesión, sin embargo, solo funciona si está utilizando un solo hilo de trabajo o si todo el estado de la sesión podría reconstruirse automáticamente si el hilo del trabajador fuera a cambiar (poco probable). Para los demás modos de almacenamiento de estado (StateServer y SQL Server), todos los objetos de estado de la sesión deben ser serializables, ya que el motor ASP.NET serializará estos objetos primero mediante serialización binaria antes de enviarlos al medio de almacenamiento.

En su caso, puede estar utilizando InProc. Sin embargo, una razón para marcar todas las clases que se usan en el estado de sesión como Serializable y probarlas de esa manera es que puede ser necesario cambiar esto en el futuro (por ejemplo, para usar un Web Farm). Si no diseña sus clases de estado de sesión con esto en mente, será bastante difícil hacer la migración en el futuro.

Además, solo porque puede eliminar el atributo Serializable y el programa "funciona" en un entorno no significa que funcione en otro entorno. Por ejemplo, puede funcionar bien en el servidor web de prueba de Visual Studio (que siempre usa el modo de estado de sesión InProc) e incluso en una instancia de desarrollo de IIS, pero luego, quizás una instancia de producción de IIS se configure para usar un modo de almacenamiento diferente.

Estas diferencias ambientales/de configuración no están necesariamente limitadas a las aplicaciones ASP.NET. Hay otros motores de aplicaciones que pueden hacer esto o incluso aplicaciones independientes que lo hacen (no es difícil crear este tipo de entorno configurable).

Finalmente, puede estar trabajando con una biblioteca que puede ser consumida por diferentes aplicaciones. Algunos pueden necesitar almacenar el estado de una manera serializable y otros pueden no.

Debido a estos factores, a menudo es una muy buena idea, al menos cuando se construye una biblioteca, considerar marcar clases de valor simples o clases de administración de estado con [Serializable]. Tenga en cuenta que esto aumenta el trabajo para probar estas clases y hay límites para lo que se puede serializar (es decir, una clase que contiene una referencia de socket o de archivo abierto puede no ser un buen candidato para la serialización ya que los recursos externos abiertos no se pueden serializar) así que no abuses de esto.

Ha preguntado si usar [Serializable] será más lento. No, no lo será Este atributo no tiene un efecto directo en el rendimiento. Sin embargo, si el entorno de la aplicación se cambia para serializar el objeto, entonces sí, el rendimiento se verá afectado. Es el acto de serializar y deserializar que es más lento que solo almacenar el objeto en el montón. [Tenga en cuenta que algunas rutinas podrían escribirse para buscar el atributo Serializable y luego elegir serializar, pero esto es raro; generalmente es como ASP.NET y deja a un administrador o usuario decidir si quiere cambiar el medio de la tienda.]

Answer 5

¿Cuáles son algunos otros usos sobre cuándo usar y cuándo no utilizar la serialización.

Déjeme darle un ejemplo práctico.En una de mis aplicaciones, me dieron XML esquemas (XSD archivos) para solicitud y respuesta XML archivos. Necesito analizar el archivo de solicitud XML, procesar y guardar la información en varias tablas. Más tarde tengo que preparar el archivo de respuesta XML en consecuencia y enviarlo a nuestro cliente.

Usé Xsd2Code para generar C# clases según el esquema. Entonces, analizar el archivo de solicitud XML es simplemente deserializar al objeto de clase de solicitud generado. Luego puedo acceder a las propiedades desde el objeto tal como aparece en el archivo de solicitud XML. Mientras se genera la respuesta XML, el archivo es simplemente serializando del objeto de clase de respuesta generado que llené en mi código. De esta manera puedo trabajar con objetos C# en lugar de archivos XML. Espero que tenga sentido.

Por ejemplo, debería siempre uso serializzation porque es más seguro

No creo que esto está relacionado con la seguridad de ninguna manera.