Почему атрибут Serializable необходим для сериализации объекта

Основываясь на моем понимании, SerializableAttribute не предоставляет никаких проверок времени компиляции, как это было сделано во время выполнения. Если это так, то почему требуется, чтобы классы были помечены как сериализуемые?

Не может ли сериализатор просто попытаться сериализовать объект, а затем сработает? Разве это не то, что он делает прямо сейчас? Когда что-то помечено, он пытается и терпит неудачу. Не было бы лучше, если бы вам пришлось пометить вещи как unserializable, а не сериализуемые? Таким образом, у вас не возникло бы проблемы с библиотеками, которые не маркировали бы вещи как сериализуемые?

Ответ 1

Как я понимаю, идея SerializableAttribute заключается в создании системы opt-in для двоичной сериализации.

Имейте в виду, что в отличие от XML-сериализации, которая использует общедоступные свойства, двоичная сериализация по умолчанию захватывает все частные поля.

Не только это может включать структуры операционной системы и частные данные, которые не должны быть раскрыты, но десериализация может привести к поврежденному состоянию, которое может привести к сбою приложения (глупый пример: дескриптор для файл открывается на другом компьютере).

Ответ 2

Это только требование для BinaryFormatter (и эквивалент SOAP, но никто не использует это). Диего прав; есть веские причины для этого с точки зрения того, что он делает, но это далеко не единственный вариант - действительно, лично я рекомендую только BinaryFormatter для разговора между AppDomains - это не (IMO ) хороший способ сохранить данные (на диск, в кеш, на BLOB базы данных и т.д.).

Если это вызывает проблемы, рассмотрите возможность использования любой из альтернатив:

XmlSerializer, который работает с публичными членами (а не только с полями), но требует публичного конструктора без параметров и открытого типа
DataContractSerializer, который может полностью работать (используя [DataContract]/[DataMember]), но который также может (в 3.5 и выше) работать с полями вместо

Также - для стороннего варианта (я являюсь третьим лицом); у protobuf-net могут быть варианты здесь; "v2" (еще не полностью выпущенный, но доступный как источник) позволяет моделировать (какие члены сериализовать и т.д.) описывать независимо от типа, чтобы его можно было применять к типам, которые вы не контролируете. И в отличие от BinaryFormatter вывод является версионным, известным общедоступным форматом и т.д.