Perché è necessario l’attributo serializzabile per la serializzazione di un object

Sulla base delle mie conoscenze, SerializableAttribute non fornisce alcun controllo del tempo di compilazione, poiché è tutto fatto in fase di runtime. Se questo è il caso, allora perché è necessario che le classi siano contrassegnate come serializzabili?

Non è ansible che il serializzatore tenti di serializzare un object e poi fallisca? Non è quello che fa adesso? Quando qualcosa è segnato, prova e fallisce. Non sarebbe meglio se dovessi contrassegnare le cose come non serializzabili piuttosto che serializzabili? In questo modo non avresti il ​​problema delle librerie che non contrassegnano le cose come serializzabili?

A quanto ho capito, l’idea alla base di SerializableAttribute è quella di creare un sistema opt-in per la serializzazione binaria.

Tieni presente che, a differenza della serializzazione XML, che utilizza le proprietà pubbliche, la serializzazione binaria acquisisce automaticamente tutti i campi privati.

Non solo questo potrebbe includere strutture del sistema operativo e dati privati ​​che non dovrebbero essere esposti, ma la deserializzazione potrebbe causare uno stato corrotto che può causare il crash di un’applicazione (esempio stupido: un handle per un file aperto in un altro computer).

Questo è solo un requisito per BinaryFormatter (e l’equivalente SOAP, ma nessuno lo usa). Diego ha ragione; ci sono buone ragioni per questo in termini di ciò che fa, ma è lontano dall’unica opzione – anzi, personalmente raccomando solo BinaryFormatter per parlare tra AppDomains – non è (IMO) un buon modo per mantenere i dati (su disco, nella cache, in un database BLOB, ecc.).

Se questo comportamento ti causa problemi, considera l’utilizzo di una delle alternative:

  • XmlSerializer , che funziona su membri pubblici (non solo sui campi), ma richiede un costruttore pubblico senza parametri e un tipo pubblico
  • DataContractSerializer , che può funzionare completamente opt-in (utilizzando [DataContract] / [DataMember] ), ma che può anche (in 3.5 e sopra) lavorare contro i campi invece

Inoltre – per un’opzione di terze parti (io sono la terza parte); protobuf-net potrebbe avere opzioni qui; “v2” (non ancora completamente rilasciato, ma disponibile come sorgente) consente al modello (quali membri di serializzare, ecc.) di essere descritto indipendentemente dal tipo, in modo che possa essere applicato a tipi che non si controllano. E a differenza di BinaryFormatter, l’output è tollerante alla versione, formato pubblico noto, ecc.