Comments 12
Касаемо сериализации есть еще один очень полезный совет, который скорее всего сделает неактуальными все остальные — по возможности вообще не использовать ISerializable и всякие там BinaryFormatter. В 98% случаев это излишне и DataContract-ы удобнее, а там свои особенности.
Или вообще кастомная сериализация в какой-нибудь Json через рефлекшн и кеширование типов — еще быстрее.
Ага, вам же снаружи виднее, что там у класса внутри и как хранится.
Только класс может знать как он сериализуется и десериализуется, больше никто. Остальные могут попытаться угадать, но где гарантии то?
Скорость не так важна, как качество.
Только класс может знать как он сериализуется и десериализуется, больше никто. Остальные могут попытаться угадать, но где гарантии то?
Скорость не так важна, как качество.
снаружи виднее, что там у класса внутри и как хранится.
Для этого делается разметка атрибутами сериализации, включая игнорирование и переименовывание для оптимизации того же трафика, например.
Только класс может знать как он сериализуется и десериализуется
Только разработчик знает как и что должно быть сериализовано, что нужно, а что не очень и может быть восстановлено из других данных.
Ага, ну т.е. в классе расставляется разметка согласно каким то методическим рекомендациям, по ней автоматически собираются значения и гоняются. Плюс то разве что в том, что можно использовать аттрибуты вместо заполнения метода с описанием сериализации. Остальное — остается.
Ну и получается, что все описанные в статье проблемы просто уходят — не нужно никакого дополнительного кода для каждого класса, только разметка атрибутами важных свойств.
Никуда оно не девается. Просто вместо обычного кода вида «info.AddValue(»flushMode", flushMode);" вы ставите аттрибут.
Забыли строчку кода \ забыли аттрибут — сериализация некорректна. Собсна, никакой магии, способы равнозначны по трудоемкости.
Забыли строчку кода \ забыли аттрибут — сериализация некорректна. Собсна, никакой магии, способы равнозначны по трудоемкости.
Не равнозначны. GetObjectData + конструктор это тонны обезъяньей работы и ненужного нечитаемого кода.
Как минимум требуется указывать все дважды — и в конструкторе и в GetObjectData. Если класс большой то чтобы понять сериализуется свойтсво или нет придется прокручивать в метод сериализации и смотреть что там происходит. А атрибут видно сразу. Плюс метаданные дают больше возможностей для генерации кода если это вдруг необходимо где может понадобиться информация о том что сериализуется а что нет. Плюс не надо копипастить конструкторы десериализации в наследные классы.
Ну и справедливости ради следует отметить что, если говорить о способах «из коробки», то при сериализации в общем случае атрибуты свойствам вообще указывать не обязательно, только для тех свойств которые следует игнорировать, а они есть не всегда, и Serializable самому классу (а если есть parameterless конструктор то для datacontractserializer-ов даже это необязательно, т.е. вообще ничего не нужно).
Итого, ISerializable применим только когда необходимо сделать совместимость с каким то определенным форматом или для каких то хитроумных оптимизаций. Для обычной повседневной сериализации, а это подавляющее большинство случаев, использование этого интерфейса должно заворачиваться на code review с последующей раздачей пинков людям его написавшим.
Как минимум требуется указывать все дважды — и в конструкторе и в GetObjectData. Если класс большой то чтобы понять сериализуется свойтсво или нет придется прокручивать в метод сериализации и смотреть что там происходит. А атрибут видно сразу. Плюс метаданные дают больше возможностей для генерации кода если это вдруг необходимо где может понадобиться информация о том что сериализуется а что нет. Плюс не надо копипастить конструкторы десериализации в наследные классы.
Ну и справедливости ради следует отметить что, если говорить о способах «из коробки», то при сериализации в общем случае атрибуты свойствам вообще указывать не обязательно, только для тех свойств которые следует игнорировать, а они есть не всегда, и Serializable самому классу (а если есть parameterless конструктор то для datacontractserializer-ов даже это необязательно, т.е. вообще ничего не нужно).
Итого, ISerializable применим только когда необходимо сделать совместимость с каким то определенным форматом или для каких то хитроумных оптимизаций. Для обычной повседневной сериализации, а это подавляющее большинство случаев, использование этого интерфейса должно заворачиваться на code review с последующей раздачей пинков людям его написавшим.
Ну и самое неочевидное — ни в коем случае нельзя использовать BinarySerializer, потому что он внутри прописывает strong-name-ы типов, что может привести к фейлу при апгрейде FW или при кросс-платформенном взаимодействии FW <-> Mono.
В жутких Enterprice может быть, но .NET вышел на рынок микросервисов и систем с отличной производительностью (после выпуска .NET Core), так что все эти Serialization, XML, Web Services, WCF (там где не нужно) уже сейчас выглядит уныло, монструозно и очень медленнно. По возможности, от всего этого нужно уходить, и многие компании, уже начали избавлять от этого болота, с которым сейчас у всех ассоциируется .NET (медлительность, неповоротливость, сис. требования).
Если продолжать разрабатывать в старом стиле, но однажды ваш проект по частям перепишут проворные люди на каком-нибудь NodeJs или Go (да-да, они влезают в Enterprise) и заставят поверить ваше руководство в то, что .NET медленное д… мо и от него нужно отказываться.
Люди, работающие в Mail.ru. Yandex, которые пишут прикладные вещи на своих тормозных скриптовых языках до сих пор на лекциях говорят, что для того, чтобы запустить сайт на .NET или Java — нужна целая стойка серверов и честно, от такого уши загибаются в трубочку и хочется смеяться…
Если продолжать разрабатывать в старом стиле, но однажды ваш проект по частям перепишут проворные люди на каком-нибудь NodeJs или Go (да-да, они влезают в Enterprise) и заставят поверить ваше руководство в то, что .NET медленное д… мо и от него нужно отказываться.
Люди, работающие в Mail.ru. Yandex, которые пишут прикладные вещи на своих тормозных скриптовых языках до сих пор на лекциях говорят, что для того, чтобы запустить сайт на .NET или Java — нужна целая стойка серверов и честно, от такого уши загибаются в трубочку и хочется смеяться…
ну или msgpack
Sign up to leave a comment.
Как не наступить на грабли, работая с сериализацией