Serializzazione Java: vantaggi e svantaggi, utilizzare o evitare? [chiuso]

La serializzazione viene utilizzata per la persistenza in Java. Potrebbe andare bene persistere alcuni oggetti usando la serializzazione. Ma, per un gran numero di oggetti, ORM, Database, ecc. Potrebbero essere migliori. Sembra che la serializzazione sia utile solo per piccoli lavori. Forse mi sbaglio. Quindi, per favore, dimmi quali sono i vantaggi della serializzazione rispetto ai metodi non di serializzazione? Quando dovrebbe essere usato e quando dovrebbe essere evitato?

Questa domanda mi è venuta in mente dopo aver visto l'articolo di DZone È la serializzazione degli oggetti male?

E queste sono le linee che hanno dato origine alla mia domanda:

Se si guardano Java e i suoi oggetti sessione, viene utilizzata la serializzazione pura dell'oggetto. Supponendo che una sessione dell'applicazione abbia una durata piuttosto breve, il che significa al massimo poche ore, la serializzazione degli oggetti è semplice, ben supportata e integrata nel concetto Java di una sessione. Tuttavia, quando la persistenza dei dati è per un periodo di tempo più lungo, possibilmente giorni o settimane, e devi preoccuparti delle nuove versioni dell'applicazione, la serializzazione diventa rapidamente malvagia. Come ogni buon sviluppatore Java sa, se si prevede di serializzare un oggetto, anche in una sessione, è necessario un ID di serializzazione reale (serialVersionUID), non solo 1L, e è necessario implementare l'interfaccia serializzabile. Tuttavia, la maggior parte degli sviluppatori non conosce le vere regole alla base del processo di deserializzazione Java. Se il tuo oggetto è cambiato, oltre ad aggiungere semplici campi all'oggetto, è possibile che Java non possa deserializzare correttamente l'oggetto anche se l'ID di serializzazione non è stato modificato. Improvvisamente, non è più possibile recuperare i dati, il che è intrinsecamente negativo.

Ora, gli sviluppatori che leggono questo articolo potrebbero dire che non scriverebbero mai codice che avrebbe questo problema. Questo può essere vero, ma che dire di una libreria che usi o di qualche altro sviluppatore non più impiegato dalla tua azienda? Potete garantire che questo problema non accadrà mai? L'unico modo per garantire che è utilizzare un diverso metodo di serializzazione.

La serializzazione viene utilizzata principalmente in due aree:

• prototipazione della persistenza

  praticamente ogni grafico a oggetti può essere rapidamente reso serializzabile, per una rapida dimostrazione di concetti o applicazioni quick-and-dirty questo potrebbe essere più veloce della configurazione di un vero livello ORM o di un altro sistema di persistenza

• conservazione a breve termine di oggetti quasi arbitrari:

  I server delle applicazioni, ad esempio, hanno la tendenza a conservare le informazioni sulla sessione usando la serializzazione. Ciò ha il vantaggio che i valori nella sessione possono essere praticamente di qualsiasi tipo (purché sia ​​serializzabile).

Per quasi tutti gli altri usi, gli svantaggi che tu (e l'articolo) menzioni sono troppo grandi: il formato esatto è difficile da mantenere stabile, i cambi di classe possono facilmente rendere illeggibili i tuoi dati serializzati, la lettura / scrittura dei dati in codice non Java è quasi impossibile (o almeno molto più difficile del necessario).

JAXB e tecnologie simili forniscono funzioni simili con un costo altrettanto basso, riducendo al contempo alcuni dei problemi.

Uso la serializzazione degli oggetti per consentire l'analisi post mortem in caso di un errore imprevisto nella produzione. Gli input per un calcolo sono serializzati in un file di dati. Se viene segnalato un errore, un semplice programma può ricaricare gli input ed eseguire nuovamente il calcolo con un debugger collegato. Oppure è possibile utilizzare una conchiglia rigida per ricaricare gli oggetti e modificarli se lo si desidera.

Utilizziamo anche la serializzazione per passare oggetti Java tramite HTTP a un servizio Web. Molto più semplice della serializzazione da e verso il testo. Lo svantaggio è che le installazioni client e server devono essere distribuite insieme, ma questo non è un problema poiché controlliamo entrambe le estremità.

Quali sono i vantaggi della serializzazione rispetto ai metodi di non serializzazione?

La serializzazione Java presenta alcuni vantaggi:

• Integrato nel sistema : non è necessario fare affidamento su strumenti, librerie o configurazioni di terze parti.

• Relativamente semplice da capire , almeno all'inizio.

• Ogni sviluppatore lo sa (o dovrebbe). Indipendentemente dal fatto che gli sviluppatori Java approvino o disapprovino, è probabile che abbiano familiarità con la serializzazione di oggetti Java.

E, naturalmente, ci sono degli svantaggi:

• Evita il flusso standard di Java. Alloca memoria ma non chiama un costruttore, quindi i campi transitori non vengono inizializzati. I campi sono inizializzati in ordine alfabetico, non in ordine di origine.

• Non così efficiente in termini di spazio, ma neanche orribile. Potresti voler comprimere il risultato.

• Fragile a meno che non prenda precauzioni quando cambiano gli oggetti. E anche allora.

Quando dovrebbe essere usato e quando dovrebbe essere evitato?

Utilizzare quando :

• Le dimensioni della distribuzione sono importanti. Integrato nel sistema, quindi 0 byte extra.

• Tutti gli attori useranno versioni compatibili.

• L'archiviazione a lungo termine non è un problema.

Evitare quando :

• Nessuno dei precedenti non si applica.

La serializzazione e un ORM / database sono cose diverse, sebbene vi siano alcune sovrapposizioni.

Un oggetto serializzato rappresenta tutte le informazioni necessarie per "scongelare" un oggetto persistente e ripopolarne i dati. Un ORM e un database mantengono i dati in un database. Una classe può avere campi di informazioni che non sono memorizzati nel database dall'ORM, ad esempio un campo calcolato.

Inoltre, la serializzazione e un ORM stanno risolvendo diversi problemi. La serializzazione risolve il problema della persistenza di un grafico a oggetti in un flusso (memoria, file system, ecc.). Un ORM gestisce la mappatura di informazioni sulle colonne del database e il recupero e la creazione di istanze di oggetti, oltre a fornire dettagli come la ricerca e il caricamento lento.

Utilizzare un ORM quando si desidera conservare i dati in un database per situazioni in cui si ha a che fare con grandi quantità di dati o che richiedono report, ricerche / query, deposito o altre cose in cui i database sono bravi. Utilizzare la serializzazione quando si desidera salvare una rappresentazione delle proprie strutture dati su disco.

La serializzazione è usata raramente in pratica.

Come già accennato, il caso d'uso più comune per la serializzazione è l'archiviazione di oggetti come BLOB in un database di sessioni. Questo funziona bene per due motivi: le sessioni tendono ad avere una vita breve e il database delle sessioni non ha alcuna conoscenza di come mappare oggetti arbitrari su un modello relazionale.

Per i dati che devono essere conservati per lunghi periodi di tempo (come un carrello di Amazon), è consigliabile archiviare tali dati in un database.

Il meccanismo di persistenza della sessione garantisce che un utente con una sessione attiva venga restituito allo stesso server. Il database delle sessioni è accessibile solo quando un server si guasta e l'utente viene reindirizzato a un nuovo server. Il nuovo server rileva una sessione attiva, ma non la trova in memoria, quindi tenta di recuperarla dal database delle sessioni nel tentativo di fornire all'utente un'esperienza senza interruzioni.

Ci sono due problemi con questo approccio:

Innanzitutto, scaricare i dati della sessione nel database delle sessioni è un processo lento. L'eliminazione dei dati della sessione troppo spesso peggiora le prestazioni e la maggior parte dei server è configurata per scaricare ogni 30 secondi, o ogni minuto o più. Questa soluzione di "failover" apparente non è mai efficace al 100%.

In secondo luogo, la mia esperienza è che la maggior parte dei clienti concorda sul fatto che vomitare un messaggio di errore che chiede all'utente di accedere e riprovare durante i rari casi in cui un server non funziona. In questo caso, disattiviamo del tutto il database delle sessioni e ci godiamo l'incremento delle prestazioni.

Un altro uso della serializzazione è quello di fornire tempi di risposta più rapidi utilizzando framework come Flex che utilizzano la serializzazione e la compressione dei grafici degli oggetti per le interazioni server-client.

Come altri hanno sottolineato, ci sono alcuni motivi creativi e utili per utilizzare la serializzazione, ma questi sono rari nella pratica.

Storicamente la serializzazione è difficile da implementare correttamente e affidabilità, limitando il suo utilizzo a un numero limitato di casi. La maggior parte degli sviluppatori non serializzerà mai gli oggetti da soli, ma può fare affidamento su framework che lo fanno dietro le quinte.

Risposta breve a "quando utilizzare la serializzazione Java" e "quando evitare la serializzazione Java"

Utilizzare la serializzazione Java se

• dovrebbero essere necessarie poche codifiche
• non importa che i dati binari non siano leggibili dall'uomo
• la ricerca nei dati serializzati non è necessaria (non è possibile eseguire query simili a database)
• o
  • la struttura dei dati serializzati non cambia o
  • non importa se i dati serializzati memorizzati non sono più leggibili dopo "modifica della struttura dei dati" (ad es. dati di sessione in un'app Web)

In tutte le altre situazioni, la "serializzazione binaria di Java" è errata

alternative

• serializzazione xml
• database nosql
• database relazionale con ORM