.NET → C# и нечувствительная сериализация из песочницы
Очень часто при работе над каким-либо проектом (как учебным, так и коммерческим) я сталкиваюсь с необходимостью сохранения каких-либо сложных данных на диск и чтения их оттуда. Казалось бы — сделай свой формат, хоть текстовый, хоть бинарный, опиши методы чтения/записи и пользуйся, ни о чем не думая.
Однако со временем возникают две проблемы. Первая связана с увеличением количества данных: если файл хранит в себе несколько десятков, а то и сотен совершенно различных значений, то поддерживать методы для сохранения и загрузки становится тяжеловато и хочется некой автоматизации. Вторая проблема несколько сложнее. Представим себе, что со временем нам начинает требоваться запихивать в наш файл все больше и больше данных (конечно, при хорошем проектировании подобные вещи не должны возникать, но где вы видели хорошее проектирование в учебных проектах? да и в коммерческих такое сплошь и рядом). При этом продукт уже используется и уже сохранено достаточное количество файлов, не содержащих эти данные, но которые надо уметь загружать и использовать. Понятно, что описывать каждый формат вручную и пытаться распознать, какую же версию файла нам подсовывают — не выход.
В этой статье я хочу рассказать о том, как сделать свой формат данных, нечувствительный к изменению и работающий с любой из своих предыдущих версий.
Сразу хочу предупредить, что для самой процедуры чтения/записи файла я буду использовать бинарную сериализацию. Кое-что из того, что будет сказано в дальнейшем, применимо и к XML-сериализации, но в своей текущей работе мы с коллегами используем именно бинарную (из-за меньшего объема получающихся файлов и большей скорости работы системы в целом).
Неудивительно, что вышеописанная проблема имеет не одно решение. Я расскажу о двух вариантах, каждый из которых имеет свои особенности.
Однако со временем возникают две проблемы. Первая связана с увеличением количества данных: если файл хранит в себе несколько десятков, а то и сотен совершенно различных значений, то поддерживать методы для сохранения и загрузки становится тяжеловато и хочется некой автоматизации. Вторая проблема несколько сложнее. Представим себе, что со временем нам начинает требоваться запихивать в наш файл все больше и больше данных (конечно, при хорошем проектировании подобные вещи не должны возникать, но где вы видели хорошее проектирование в учебных проектах? да и в коммерческих такое сплошь и рядом). При этом продукт уже используется и уже сохранено достаточное количество файлов, не содержащих эти данные, но которые надо уметь загружать и использовать. Понятно, что описывать каждый формат вручную и пытаться распознать, какую же версию файла нам подсовывают — не выход.
В этой статье я хочу рассказать о том, как сделать свой формат данных, нечувствительный к изменению и работающий с любой из своих предыдущих версий.
Сразу хочу предупредить, что для самой процедуры чтения/записи файла я буду использовать бинарную сериализацию. Кое-что из того, что будет сказано в дальнейшем, применимо и к XML-сериализации, но в своей текущей работе мы с коллегами используем именно бинарную (из-за меньшего объема получающихся файлов и большей скорости работы системы в целом).
Неудивительно, что вышеописанная проблема имеет не одно решение. Я расскажу о двух вариантах, каждый из которых имеет свои особенности.
PHP → PDO: сериализация, поздняя инициализация и PHPUnit
Здравствуйте. Как известно, PDO не поддерживает сериализацию. С этим связано несколько интересных вещей, в частности сюрпризы с трейсами и невозможность сделать mock от PDO в PHPUnit.
Я активно использую PHPUnit и реализуя в очередной раз паттерн Dependency Injection столкнулся с описанными трудностями создания Mock-объекта от PDO.
Я активно использую PHPUnit и реализуя в очередной раз паттерн Dependency Injection столкнулся с описанными трудностями создания Mock-объекта от PDO.
.NET → Использование Protocol Buffers на платформе .Net (Часть 1)
Предлагаю вашему вниманию введение в использование Protocol Buffers на платформе .Net в формате дискуссии. Я расскажу и покажу что это такое и зачем оно нужно .Net разработчику. Топик требует от читателя начального владения языком C# и системой контроля версий SVN. Так как объем материала превышает среднестатистический объем топиков на хабре, которые не вгоняют хаброюзеров в тоску и не заставляют их скроллить до комментариев, было принято решение разбить его на две части. В первой части мы познакомимся с основами и даже напишем (не)много кода!
Разработка под Android → Разбор XML при помощи Simple Framework
Здравствуйте, читатели Хабрахабр!
Данный пост навеян другим постом и комментарием уважаемого хабраюзера AnatolyB оттуда.
Я думаю, что многие знакомы с данной библиотекой, но, тем не менее, оказалось, что она еще не была отражена на страницах Хабры. Исправлением этого недоразумения мы и займемся сегодня.
И, конечно же, тем, кто еще не знаком с этой прекрасной библиотекой, рекомендую скорее познакомиться, я же постараюсь в этом вам помочь.
PHP → Производительность функции unserialize
В PHP есть две замечательные функции serialize и unserialize. Первая преобразует в строку практически любой набор данных, вторая производит обратное преобразование. Эти функции удобно использовать при организации кеширования или хранения сессий в базе данных. Я обнаружил, что время работы функции unserialize может оказаться неожиданно большим.
PHP → XML-сериализация в духе .NET для PHP 5.3
В дотнете есть XML-сериализация, которая мне нравится:
И либо я плохо гуглил, либо такого в природе правда нету, но для PHP ничего подобного не нашел. Нет, про SimpleXML и PEAR::Xml_Serializer я слышал, но все-таки это немножко не того уровня инструменты.
Итак, я решил написать свой XML-сериализатор для PHP 5.3. В нем сериализуемые свойства помечаются doc-comment аннотациями вот так:
И либо я плохо гуглил, либо такого в природе правда нету, но для PHP ничего подобного не нашел. Нет, про SimpleXML и PEAR::Xml_Serializer я слышал, но все-таки это немножко не того уровня инструменты.
Итак, я решил написать свой XML-сериализатор для PHP 5.3. В нем сериализуемые свойства помечаются doc-comment аннотациями вот так:
JAVA → Преобразование объектов Java в формат JSON и обратно
В поисках библиотеки для работы с JSON в Java, наткнулся на интересный проект google-gson.
В кратце, Gson — это Java библиотека, которая может быть использована для преобразования Java объектов в представление JSON, а так же для обратного преобразования JSON в объекты Java. Gson может работать с произвольными объектами Java, включая объекты к исходным кодам которых вы не имеете доступа.
Существует несколько подобных проектов, но большинство из них требует размещения аннотаций в исходном коде, для того, чтобы была возможность сериализации в JSON, что является проблемой, когда доступа к исходным кодам нет.
В кратце, Gson — это Java библиотека, которая может быть использована для преобразования Java объектов в представление JSON, а так же для обратного преобразования JSON в объекты Java. Gson может работать с произвольными объектами Java, включая объекты к исходным кодам которых вы не имеете доступа.
Существует несколько подобных проектов, но большинство из них требует размещения аннотаций в исходном коде, для того, чтобы была возможность сериализации в JSON, что является проблемой, когда доступа к исходным кодам нет.
JAVA → Сериализация в Java
Сериализация это процесс сохранения состояния объекта в последовательность байт; десериализация это процесс восстановления объекта, из этих байт. Java Serialization API предоставляет стандартный механизм для создания сериализуемых объектов. В этой статье вы увидите как сериализовать объект, и почему сериализация иногда необходима. Вы узнаете об алгоритме сериализации используемом в Java и увидите пример, который иллюстрирует сериализованый формат объекта. В конце у вас должно сложиться чёткое представление о том, как работает алгоритм сериализации, а так же каким образом представлены части объекта в сериализованном виде.
JAVA → java.io.Serializable и наследование
Что такое сериализация можно почитать в отличной статье Евгения Матюшкина.
Я же отмечу случай с этим чудом техники в аспекте наследования классов. Интерфейс Serializable не требует от разработчика никаких действий, однако важно помнить, что внутренний механизм сериализует лишь поля этого класса и поля наследников, а поля родителя будут инициализированы с помощью конструктора без параметров.
Я же отмечу случай с этим чудом техники в аспекте наследования классов. Интерфейс Serializable не требует от разработчика никаких действий, однако важно помнить, что внутренний механизм сериализует лишь поля этого класса и поля наследников, а поля родителя будут инициализированы с помощью конструктора без параметров.
Персональные блоги → XmlSerializer — Assembly Leak без спроса :)
Коротко о главном
В некоторых частях .NET Framework, таких как XmlSerializer, используется внутреннее динамическое создание кода.XmlSerializer создает временные файлы C#, компилирует результирующие файлы во временную сборку и затем загружает эту сборку в процесс. Такое создание кода тоже стоит сравнительно дорого, поэтому XmlSerializer размещает временные сборки в кэш, по одной на каждый тип. Это значит, что в следующий раз при создании кода XmlSerializer для класса Х не будет создаваться новая сборка, а будет использована сборка из кэша. Однако, не все так просто.