Por qué se requiere un atributo serializable para serializar un objeto

Question

Según lo que sé, SerializableAttribute no proporciona comprobaciones de tiempo de compilación, ya que todo se hace en tiempo de ejecución. Si ese es el caso, ¿por qué es necesario que las clases se marquen como serializables?

¿No pudo el serializador simplemente intentar serializar un objeto y luego fallar? ¿No es eso lo que hace ahora? Cuando algo está marcado, lo intenta y falla. ¿No sería mejor si tuvieras que marcar las cosas como no serializables en lugar de serializables? De esa forma, ¿no tendrías el problema de que las bibliotecas no marcan las cosas como serializables?

Answer 1

Según tengo entendido, la idea detrás de SerializableAttribute es crear un opt-in sistema para la serialización binaria.

Tenga en cuenta que, a diferencia de la serialización XML, que utiliza propiedades públicas, la serialización binaria toma todos los campos privados de forma predeterminada.

No sólo esto podría incluir las estructuras del sistema operativo y los datos privados que no se supone que es expuesta, pero deserializar que podría resultar en estado corrupto que puede bloquearse una aplicación (ejemplo tonto: un mango para un archivo abierto en una computadora diferente).

Answer 2

Esto es solo un requisito para BinaryFormatter (y el equivalente de SOAP, pero nadie lo usa). Diego tiene razón; hay buenas razones para ello en términos de lo que hace, pero es ahora de la única opción - de hecho, en lo personal yo sólorecomiendo BinaryFormatter para hablar entre AppDomains - es no (OMI) una buena manera de persistir datos (a disco, en caché, a una base de datos BLOB, etc.).

Si este comportamiento hace que problemas, considerar el uso de cualquiera de las alternativas:

• XmlSerializer, que trabaja en los miembros públicos (no sólo los campos), pero exige un constructor sin parámetros pública y el tipo de público
• DataContractSerializer, que puede trabajo totalmente opt-in (usando [DataContract]/[DataMember]), pero que puede también (en 3.5 y superior) en contra de los campos en lugar

También, para una opción de terceros (yo soy el tercero); protobuf-net puede tener opciones aquí; "v2" (aún no se ha lanzado por completo, pero está disponible como fuente) permite que el modelo (qué miembros serializar, etc.) se describa independientemente del tipo, para que se pueda aplicar a los tipos que no controla. Y a diferencia de BinaryFormatter, la salida es tolerante a la versión, formato público conocido, etc.