Разработчики должны "выбирать" для создания сериализуемых классов, явно используя SerializableAttribute. Что может пойти не так, если классы по умолчанию были сериализованы?
Почему классы по умолчанию не сериализуются в .Net?
Ответ 1
Я бы предположил, что классы по умолчанию не сериализуются, потому что нет гарантии, что дамп состояния объекта потоку с использованием Reflection даже имеет смысл. Что делать, если ваш объект имеет открытое соединение с база данных или порт связи? Всякий раз, когда новый объект был создан путем десериализации экземпляра предыдущего объекта, вы попадаете в бесполезный объект.
Кроме того, вы должны учитывать, что всякий раз, когда класс сериализуется, среда выполнения настаивает на том, что все ее переменные-члены также могут быть сериализуемыми, если они явно не обозначены иначе. Гораздо проще сделать сериализуемость опцией для разработчиков, а не заставить их отказаться от определенных членов.
И, наконец, у вас могут быть определенные поля в вашем классе, которые содержат конфиденциальную или конфиденциальную информацию. Чтобы явно маркировать классы как сериализуемые, вы гарантируете, что вы случайно не представите информацию о чем-либо (будь то данные или ваша реализация) миру, что вы не хотели быть публичными.
Ответ 2
Сериализуемые классы подразумевают, что они имеют какое-то состояние, которое можно записать во внешнее местоположение и прочитать снова. Для многих классов, которые не имеют никакого смысла вообще - какое состояние имеет Thread, что вы можете успешно сериализовать?
Это немного философски, но по соглашению тип класса по умолчанию не является сериализуемым, если вы явно не определяете "этот класс может быть сериализован".
Ответ 3
IMO [Serializable] запутан, в основном потому, что он действительно не, требуемый большинством сериализации. Под этим я имею в виду: есть больше кода, использующего XmlSerializer (включая asmx), DataContractSerializer (включая WCF), JavaScriptSerializer (включая MVC JsonResult) или такие вещи, как protobuf-net и т.д. [Serializable] - это в основном BinaryFormatter, который (из чего я см.) в определенном снижении. и с множеством веских причин.
Что касается того, почему: другие ответы касаются этого, но не всегда имеет смысл сериализовать что-то. Конечно, объекты объекта могут действовать как DTO, но это трудно обнаружить надежным способом.
Таким образом, IMO оказывает незначительное влияние на то, является ли я [Serializable] или нет, но я согласен с дефолтом: вы должны знать, что планируете сериализовать что-то. В некоторых случаях эта сериализация означает дополнительную работу (особенно, поскольку некоторые сериализаторы не запускают код ctor/init, поэтому вам необходимо знать, чтобы подготовить поля соответственно).
Ответ 4
Принцип замены Лискова подразумевает, что если класс сериализуем, все производные классы также должны быть сериализуемыми. Если классы по умолчанию были сериализуемыми, было бы очень сложно получить несериализуемые классы, не нарушая Принципа замещения Лискова.
Ответ 5
Вероятно, лучше всего пометить все классы как сериализуемые, если только:
- Они никогда не будут пересекать домен приложения. Если сериализация не требуется и класс должен пересекать домен приложения, выведите класс из MarshalByRefObject.
- В классе хранятся специальные указатели, которые применимы только к текущему экземпляру класса. Например, если класс содержит неуправляемую память или файловые дескрипторы, убедитесь, что эти поля отмечены как NonSerialized или вообще не сериализуют класс.
- Некоторые элементы данных содержат конфиденциальную информацию. В этом случае, вероятно, целесообразно реализовать ISerializable и сериализовать только необходимые поля.