Se lo chiedono, come riferito dal mitico ughetto, anche il Cradle nonchè il Mostardone. Parliamone :-) Innanzitutto, leggete sia il post originale sia il thread dei commenti, che IMVHO è anche più interessante della domanda in oggetto <g>
Ma torniamo a quel "cavolo" di SerializableAttribute: perchè essere costretti a decorare un oggetto in tal modo? A prima vista, in effetti è inutile: io voglio "solo" che EF/WCF/vattelapesca possa restituire col minimo sforzo un grafo e "minimo sforzo" significa "usa le mie classi as is e non chiedermi nulla di più". Insomma: parafrasando una famosa canzone eighties (Imagination) "Serialization, that's all I want from you!". E poi io sono un talebano fan sostenitore della "infrastructure ignorance", quindi per coerenza dovrei unirmi alla lista dei sostenitori del quesito :-)
Il problema è: cosa significa serializzare? Se accettiamo che la serializzazione sia "solo" una implementazione idiomatica di Memento [GoF] allora la decorazione in effetti è inutile. Ma se desiderassimo che la copia deserializzata di un oggetto possa supportare gli stessi casi d'uso dell'oggetto originale, la musica cambierebbe: come si potrebbe garantire che una copia deserializzata di un oggetto di tipo SqlConnection o Thread possa essere utilizzabile? Tanto per fare un esempio, nel primo caso il DBMS potrebbe essere attivo al momento della apertura+serializzazione dell'oggetto connection, salvo poi risultare "spento" al momento della reidratazione. Ecco quindi che decorare un oggetto significa affermare che il "clone" funzionerà. E poichè non tutti gli oggetti potrebbero sopravvivere *funzionalmente* ad un processo di (de)serializzazione, ecco che affermare esplicitamente quali classi siano serializzabili è "cosa buona e giusta" (cit.)
Technorati Tag:
serialization