Dove esattamente la serializzazione entra nell'immagine? Ho letto di serializtion 'sulla rete e sono venuto a sapere checos'è la serializzazione?
Si tratta di un'interfaccia che implementa se in una classe, significa che può essere automaticamente essere serializzato e deserializzato dai diversi serializzatori.
Dammi una buona ragione perché e quando una classe deve essere serializzata? Supponiamo che una volta serializzato, cosa succede esattamente?
La serializzazione è necessaria ogni volta che un oggetto deve essere persistito o trasmesso oltre l'ambito della sua esistenza.
La persistenza è la possibilità di salvare un oggetto da qualche parte e caricarlo in un secondo momento con lo stesso stato. Ad esempio:
La trasmissione è la capacità di inviare un oggetto al di fuori del suo ambito originale ad un ricevitore. Ad esempio:
Per ognuno di questi, deve essere presente una rappresentazione di bit seriale che può essere memorizzata, comunicata e successivamente utilizzata per ricostituire l'oggetto originale. Il processo di trasformare un oggetto in questa serie di bit è chiamato "serializzazione", mentre il processo di trasformare la serie di bit nell'oggetto originale è chiamato "deserializzazione".
La rappresentazione reale dell'oggetto in forma serializzata può variare a seconda di quali sono i tuoi obiettivi. Ad esempio, in C#, si ha sia la serializzazione XML (tramite la classe XmlSerializer) che la serializzazione binaria (tramite l'uso della classe BinaryFormatter). A seconda delle esigenze, è anche possibile scrivere il proprio serializzatore personalizzato per eseguire operazioni aggiuntive come compressione o crittografia. Se hai bisogno di un formato di serializzazione in lingua e piattaforma neutra, puoi provare con Google Protocol Buffers che ora ha support for .NET (non l'ho usato).
La rappresentazione XML sopra menzionata è utile per archiviare un oggetto in un formato standard, ma può essere prolisso e lento a seconda delle esigenze. La rappresentazione binaria consente di risparmiare spazio ma non è così portabile tra lingue e runtime come XML. Il punto importante è che il serializzatore e il deserializzatore devono capirsi a vicenda. Questo può essere un problema quando inizi a introdurre compatibilità con versioni precedenti e precedenti e versioni.
Un esempio di potenziali problemi di compatibilità serializzazione:
Foo oggetto in un file.Foo in un file.Foo aggiornato.Questo può essere un problema se la versione 2.0 Foo ha proprietà aggiuntive che la versione 1.0 Foo non ha fatto. Devi esplicitamente non supportare questo scenario o avere qualche storia di versionamento con la tua serializzazione. .NET può fare qualcosa per te. In questo caso, potresti anche avere il problema inverso: l'utente potrebbe provare ad aprire un file versione 2.0 con la versione 1.0 del tuo programma.
Non ho usato queste tecniche me stesso, ma .NET 2.0 e versioni successive ha il supporto per version tolerant serialization per supportare sia la compatibilità in avanti e indietro:
- Tolleranza dei dati estranei o imprevisti. Ciò consente alle versioni più recenti del tipo di inviare dati a versioni precedenti.
- Tolleranza di dati opzionali mancanti. Ciò consente alle versioni precedenti di inviare dati a versioni più recenti.
- Callback di serializzazione. Ciò consente l'impostazione intelligente del valore predefinito nei casi in cui mancano i dati.
Non classi, ma gli oggetti specifici potrebbero essere serializzati per memorizzare in qualche memoria persistente o passare l'oggetto in un'altra applicazione/via rete.
Ad esempio quando si desidera inviare oggetti tramite la rete o archiviarli in file.
Diciamo che stai creando un formato Savegame per un videogioco. È quindi possibile rendere serializza la classe Player e ogni Enemy. In questo modo sarebbe facile salvare lo stato degli oggetti correnti in un file.
Dall'altra parte, quando si scrive un'implementazione multiplayer per il gioco, è possibile inviare lo Player serializzato via rete agli altri client, che quindi potrebbero gestire questi dati.
il tuo esempio è buono..thnx – FosterZ
ad esempio, quando si desidera inviare un oggetto a qualche URL, è possibile decidere di inviarlo in formato xml. Il processo di conversione dall'oggetto in memoria a (in questo caso) xml, è chiamato serializzazione. La conversione da xml a in memoria è detta de-serializzazione.
Nei linguaggi non orientati agli oggetti, uno di solito memorizza i dati in memoria in un modello di byte che avrebbe senso "senza riferimento a nient'altro. Ad esempio, un gruppo di forme in un editor di grafica potrebbe semplicemente avere tutti i loro punti memorizzati consecutivamente. In un programma di questo tipo, la semplice memorizzazione dei contenuti di tutti gli array sul disco potrebbe produrre un file che, se riletto in tali array, produrrebbe i dati originali.
Nei linguaggi orientati agli oggetti, molti oggetti sono memorizzati come riferimenti ad altri oggetti. Memorizzare semplicemente il contenuto delle strutture di dati in memoria non sarà utile, perché un riferimento all'oggetto # 24601 non dirà nulla su ciò che l'oggetto rappresenta. Mentre un sistema orientato agli oggetti può essere in grado di fare un buon lavoro nel capire cosa significano i dati in memoria e cercare di convertirli automaticamente in un formato ragionevole, non può riconoscere tutte le distinzioni tra i riferimenti dell'oggetto che puntano allo stesso oggetto e a quelli che puntano agli oggetti che corrispondono.È quindi spesso necessario aiutare il sistema durante la conversione di oggetti in un flusso grezzo di bit.
puoi darmi uno scenario o un esempio, dove l'oggetto deve essere persistito oltre la portata della sua esistenza? – FosterZ
oh nice, thanku – FosterZ
grazie per le informazioni sull'addotto 'Protocollo di Google Buffer' e' serializzazione tollerante della versione'. – FosterZ