Impactul nemarcarii unei clase ‹Serializabil()›

Presupun că atunci când spui „poți în continuare să serializezi un obiect fără să-l marchezi ca serializabil” vrei să spui că faci singur serializarea/deserializarea.

Adăugarea atributului [Serializable] indică codului terță parte că obiectul poate fi serializat. Acest lucru este util în special atunci când doriți să stocați un obiect în sesiunea ASP.NET sau într-un alt instrument (cum ar fi un cache Memcached).

Punerea [Serializable] pe un Type vă permite să-l utilizați cu [System.Runtime.Serialization][1] API-uri, care sunt destul de utile pentru cele mai obișnuite scenarii și vă scutesc de a scrie mult cod repetitiv pentru serializarea/deserializarea obiectelor, ceea ce este de obicei greoi de testat și predispus la erori. . Și vă câștigă o oarecare flexibilitate în ceea ce privește mecanismele de stocare subiacente (cum ar fi Binary, XML, SOAP...).

Dacă puneți [Serializable] pe unul dintre tipurile dvs., ar trebui să vă asigurați că se va serializa/dezerializa în mod corespunzător folosind mecanismele standard sau trebuie să implementați ISerializble pentru a controla singur procesul. Lucrurile pe care ar trebui să le evitați serializarea sunt de ex. proprietățile handlerului de evenimente.

Cel mai important, atunci când decideți dacă să utilizați Serializable sau nu este că obțineți o serializare gratuită a graficului obiect complet (obiectul rădăcină plus toate asocierile sale și asocierile lor), care altfel ar fi foarte complexă, mai ales dacă este implicată moștenirea. Dar pentru ca acest lucru să funcționeze, este nevoie să aveți toate tipurile dvs. în grafic marcate Serializable.

După cum am înțeles, ați putea folosi un surogat pentru a serializa un obiect care nu poate fi serializat, dar ce v-ar determina să faceți acest lucru? Nu cred că membrii private vor fi serializate folosind această abordare. Probabil aveți nevoie de un constructor implicit etc.