Perché utilizzare la serializzazione

Question

ho visto paio di esempi con l'attributo serializable come questo:

[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(); 
       } 
      } 

ho mai avuto una buona conoscenza sulla comprensione di come funziona, ma da msdn:

serializzazione consente allo sviluppatore di salvare lo stato di un oggetto e di ricrearlo secondo necessità, fornendo spazio per gli oggetti e lo scambio di dati . Tramite la serializzazione, uno sviluppatore può eseguire azioni come inviare l'oggetto a un'applicazione remota tramite un servizio Web , passare un oggetto da un dominio a un altro, passare un oggetto attraverso un firewall come stringa XML o mantenere la sicurezza o informazioni specifiche dell'utente attraverso le applicazioni.

Ma il problema è che nel mio esempio di codice non vedo alcun uso per questo. Solo un oggetto che viene utilizzato per recuperare i dati dal database, niente di speciale. Quali sono altri usi su quando usare e quando non usare la serializzazione. Ad esempio, dovrei sempre usare serializzation perché è più sicuro? sta andando ad essere più lento in questo modo?

Update: Grazie per tutte le risposte belle

Answer 1

serializzazione è utile ogni volta che si desidera spostare una rappresentazione dei dati all'interno o all'esterno del vostro limite di processo.

Salvare un oggetto su disco è un esempio banale che vedrai in molte esercitazioni.

Più comunemente, la serializzazione viene utilizzata per trasferire dati da e verso un servizio Web o per mantenere i dati da o verso un database.

Answer 2

La citazione MSDN che viene fornita spiega quando la serializzazione è utile: per il trasporto o la memorizzazione dei dati. La scrittura su un file è serializzazione e la serializzazione è necessaria per inviare un oggetto su una rete.

Se si sta compilando l'oggetto in una singola applicazione, forse da un database, allora effettivamente: la serializzazione non è affatto una preoccupazione. L'imaging di una classe per la serializzazione non ha alcun impatto sulla sicurezza o sulle prestazioni: se non ne hai bisogno, non preoccuparti.

Nota anche che [Serializable] si riferisce principalmente a BinaryFormatter, ma in realtà ci sono molti più serializzatori di quello. Ad esempio: potresti voler esporre il tuo oggetto tramite JSON o XML - entrambi richiedono la serializzazione, ma nessuno dei due richiede [Serializable].

Answer 3

Semplice esempio: immagina di avere una forma personalizzata per memorizzare le impostazioni dell'applicazione.

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

     public string Setting2 { get; set; } 
    } 
} 

È quindi possibile avere un file un file XML in quanto tale:

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

Utilizzando XmlSerializer si potrebbe semplicemente serializzare e deserializzare le impostazioni.

È inoltre necessario che la forma sia serializzabile se si desidera inserirla nell'ASP.NET ViewState

Questi sono esempi molto semplici, ma dimostrare è l'utilità

Answer 4

Diverse risposte hanno coperto le ragioni per cui si potrebbe desiderare di utilizzare la serializzazione in generale. Sembra anche che tu voglia sapere perché una classe specifica ha attributo [Serializable] e ti stai chiedendo perché questo potrebbe essere stato fatto.

Con ASP.NET la memoria di stato sessione predefinita è InProc che consente di memorizzare qualsiasi oggetto come riferimento e lasciarlo nell'heap. Questo è il modo migliore per memorizzare lo stato della sessione, tuttavia, funziona solo se si utilizza un singolo thread di lavoro o se è possibile ricostruire automaticamente tutto lo stato della sessione se il thread di lavoro dovesse cambiare (improbabile). Per le altre modalità di memorizzazione dello stato (StateServer e SQL Server) tutti gli oggetti dello stato sessione devono essere serializzabili poiché il motore ASP.NET prima serializzerà questi oggetti utilizzando la serializzazione binaria prima di inviarli al supporto di memorizzazione.

Nel tuo caso, potresti utilizzare InProc. Un motivo per cui è ancora possibile contrassegnare tutte le classi utilizzate in stato sessione come Serializable e verificarle in questo modo è che potrebbe essere necessario cambiarlo in futuro (ad esempio, per utilizzare una Web Farm). Se non si progettano le classi di stato della sessione tenendo presente questo, sarà molto difficile eseguire la migrazione in futuro.

Inoltre, solo perché è possibile rimuovere l'attributo Serializable e il programma "funziona" in un ambiente non significa che funzionerà in un altro ambiente. Ad esempio, può funzionare correttamente sotto il server Web di test di Visual Studio (che utilizza sempre l'istanza dello stato di sessione InProc) e anche in un'istanza di sviluppo IIS, ma in tal caso, un'istanza IIS di produzione viene configurata per utilizzare una diversa modalità di archiviazione.

Queste differenze ambientali/di configurazione non sono necessariamente limitate alle applicazioni ASP.NET. Esistono altri motori applicativi che possono eseguire questa o anche applicazioni indipendenti (non è difficile creare questo tipo di ambiente configurabile).

Infine, è possibile che si stia lavorando con una libreria che può essere utilizzata da diverse applicazioni. Alcuni potrebbero dover memorizzare lo stato in modo serializzabile e altri no.

A causa di questi fattori è spesso una buona idea, almeno quando si costruisce una libreria, considerare la possibilità di contrassegnare classi di valore o classi di gestione dello stato con [Serializable]. Tieni presente che questo aumenta il lavoro per testare queste classi e ci sono limiti a ciò che può essere serializzato (cioè una classe che contiene un riferimento socket o un riferimento a file aperti potrebbe non essere un buon candidato per la serializzazione in quanto le risorse esterne aperte non possono essere serializzate) quindi non abusare di questo.

Hai chiesto se l'utilizzo di [Serializable] sarà più lento. No, non lo sarà. Questo attributo non ha effetti diretti sulle prestazioni. Tuttavia, se l'ambiente dell'applicazione viene modificato per serializzare l'oggetto, allora sì, le prestazioni saranno influenzate. È l'atto di serializzare e deserializzare che è più lento della semplice memorizzazione dell'oggetto sull'heap. [Si noti che alcune routine potrebbero essere scritte per cercare l'attributo Serializable e quindi scegliere di serializzare, ma questo è raro; di solito è come ASP.NET e lasciato a un amministratore o utente per decidere se vogliono cambiare il mezzo di archiviazione.]

Answer 5

Quali sono alcuni altri usi su quando utilizzare e quando non utilizzare la serializzazione.

Lasciatemi fare un esempio pratico.In una delle mie applicazioni, mi sono stati dati gli schemi XML (file XSD) per i file di richiesta e risposta XML. Ho bisogno di analizzare la richiesta XML file, elaborare e salvare le informazioni in diverse tabelle. Successivamente ho bisogno di preparare il file di risposta XML di conseguenza e inviarlo al nostro cliente.

Ho utilizzato Xsd2Code per generare classi C# basate sullo schema. Quindi, l'analisi del file XML è semplicemente deserializzando nell'oggetto classe di richiesta generato. Quindi posso accedere alle proprietà dall'oggetto nel modo in cui appare nel file richiesta XML. Mentre genera la risposta il file XML è semplicemente serializzando dall'oggetto classe di risposta generato che compilo nel mio codice. In questo modo posso lavorare con oggetti C# anziché con i file XML. Spero che abbia senso.

Per esempio, usare sempre serializzation, perché è più sicuro

Non credo che questo è legato alla sicurezza in alcun modo.