Почему классы не сериализуемы по умолчанию в .Net?
Это не определенный тип C#, но я просто нашел интерфейсы ISurrogateSelector и ISerializationSurrogate -
http://msdn.microsoft.com/en-us/library/system.runtime.serialization.isurrogateselector.aspx
, http://msdn.microsoft.com/en-us/library/system.runtime.serialization.isurrogateselector.aspx
Используя их в сочетании с BinaryFormatter позволяет, чтобы несериализуемые объекты были сериализированы через реализацию суррогатного класса. Суррогатный шаблон хорошо понят в информатике, особенно при контакте с проблемой сериализации. Я думаю, что эта реализация просто убрана как параметр конструктора к BinaryFormatter, и очень жаль.
Все еще - ОЧЕНЬ скрытый.:)
3 ответа
Я бы предположил, что классы по умолчанию не сериализуемы, потому что нет гарантии, что дамп состояния объекта в поток с помощью Reflection даже имеет смысл. Что если ваш объект содержит открытое соединение с базой данных или коммуникационным портом? Всякий раз, когда новый объект был создан путем десериализации экземпляра предыдущего объекта, вы в итоге получите бесполезный объект.
Кроме того, вы должны учитывать, что всякий раз, когда класс сериализуем, среда выполнения настаивает на том, чтобы все его переменные-члены также были сериализуемыми, если только они явно не помечены иначе. Намного проще сделать сериализуемость опцией в для разработчиков, чем заставлять их отказаться от определенных членов.
И, наконец, у вас могут быть определенные поля в вашем классе, которые содержат личную или конфиденциальную информацию. Необходимость явно помечать классы как сериализуемые гарантирует, что вы не случайно представите детали чего-либо (будь то данные или ваша реализация) миру, который вы не хотели публиковать.
ИМО [Сериализуемый] сбивает с толку, в основном потому, что он не фактически требуется большинством сериализаций. Под этим я подразумеваю: имеется больше кода, использующего XmlSerializer (включает asmx), DataContractSerializer (включает WCF), JavaScriptSerializer (включает JsonResult MVC), или такие вещи, как protobuf-net и т. Д. [Serializable] в основном BinaryFormatter, то есть (из того, что я видите) в определенном упадке. и со многими вескими причинами.
Что касается того, почему: другие ответы касаются этого, но не всегда имеет смысл что-то сериализовать. Конечно, объекты объекта могут действовать как DTO, но это трудно обнаружить надежным способом.
Таким образом, IMO оказывает незначительное влияние на то, является ли я [Сериализуемым] или нет, но я согласен со значением по умолчанию: вы должны знать , что вы планируете сериализовать что-то. В некоторых случаях эта сериализация означает дополнительную работу (в частности, некоторые сериализаторы не запускают код ctor / init, поэтому вам необходимо знать, чтобы подготовить поля соответствующим образом).
Вероятно, лучше пометить все классы как сериализуемые, если:
- Они никогда не пересекают область приложения. Если сериализация не требуется и класс должен пересекать область приложения, наследуйте класс от MarshalByRefObject.
- Класс хранит специальные указатели, которые применимы только к текущему экземпляру класса. Например, если класс содержит неуправляемую память или файловые дескрипторы, убедитесь, что эти поля помечены как несериализированные или не сериализуют класс вообще.
- Некоторые из членов данных содержат конфиденциальную информацию. В этом случае, вероятно, будет целесообразно реализовать ISerializable и сериализовать только необходимые поля.