Лучшие практики для отправки / сериализации объекта

Question

Вопрос: Насколько часто разработчик создает собственный формат сериализации?В частности, я использую Java по сути отправлять объект в виде гигантской строки с токенами для разделения переменных.

Моя логика: я выбрал это, потому что это в значительной степени устраняет языковую зависимость (игнорируя модифицированный Java-код UTF-8), также у вас нет проблемы с объектной версией, где, если вы используете сериализацию Java, получающая сторона должна иметьточно такая же версия объекта, поэтому клиент, работающий на более старой версии, не сможет получить данные об объектах.Код не слишком уродливый и хорошо читается, но я думаю, мой вопрос - каковы лучшие практики для этого экземпляра?Это для личного проекта.

Другие известные варианты: Хорошо, я только что работал с сериализацией объекта для отправки его по сети и наткнулся на буферы протокола googles.Насколько стандартизирована сериализация объекта?По сути, я наткнулся на три способа сделать это.(Я собираюсь поговорить о Java здесь, потому что это то, для чего я это сделал) 1) Используйте собственные классы сериализации языка (java) 2) Используйте свой собственный способ сериализации объекта, возможно, с использованием строк и токенов 3) используйте Protocol Buffers иликакой-то другой известный формат (JSON, XML и т. д.)

Из того, что я собрал, по существу, у вас есть 3 основные цели, которые нужно достичь при сериализации: 1) Скорость / эффективность / размер 2) Независимость от языка 3) Принятие версии (при этом старые версии кода все еще могут принимать части новой версии и наоборот)

Используют ли большинство крупных программных проектов протокольные буферы?Изменится ли он, если ваш клиент - мобильное устройство с гораздо меньшими ресурсами?

Answer 1

Если вы используете стандартный формат (JSON, XML или даже прото буферы), у вас будет гораздо больше возможностей для расширения вашего приложения с помощью точек интеграции.Но если это просто внутреннее, то делай то, что легко.Лично я создаю выделенный постоянный прокси-класс, который представляет сериализованную форму данного объекта.Затем сериализуйте этот объект, используя тот метод, который имеет больше всего смысла (сериализация Java для прямых трансляций по сети, xml для долговременного хранения) с использованием writeReplace и readResolve.По мере развития класса я могу создавать совершенно новые реализации постоянного прокси, добавлять версии в прокси и т. Д., В зависимости от обстоятельств.Я полагаю, что Блох обсуждает этот паттерн в Effective Java.

Что касается разработки чисто проводного протокола, то он действительно зависит от того, насколько важна производительность для приложения.Как и в большинстве случаев, чем больше вы можете использовать стандартные библиотеки / протоколы, тем быстрее вы сможете получить новый код прямо за дверью.Когда я вижу огромный кусок кода, связанный с сериализацией / и т.д ... Я обычно считаю это запахом кода и обращаю очень пристальное внимание на то, было ли это оправданным или нет.Только мои $ 0,02.

И PS - кто-то задал вопрос о графиках ... На самом деле это одна из областей, где я намеренно избегал стандартной сериализации.Способность Java сериализовать сложные графы невелика - вы столкнетесь с проблемами переполнения стека (ха), если граф даже отдаленно сложен.В этих случаях постоянный прокси очень, очень важен.

Answer 2

Вопрос: Насколько часто разработчик создает собственный формат сериализации?

Предполагая, что вы имеете в виду создать его с нуля, тогда ответ будет "довольно необычным".

Кроме того, я бы сказал, что это не "лучшая практика", чтобы делать это в целом. В большинстве случаев одним из существующих часто используемых альтернатив (сериализация Java, JSON, XML и т. Д.) Является хорошее решение.

ИМО, вам следует рассмотреть возможность «прокатки собственного» формата (и реализации соответствующего кода сериализации / десериализации), если у вас есть четкое требование сделать это или если у вас есть четкие доказательства того, что существующие альтернативы выиграли ' т работы . Народная мудрость о том, что «XYZ медленный» не является достаточным доказательством.

Answer 3

Несколько вещей, которые сразу приходят мне в голову:

• Включите номер версии для каждого сообщения или для согласования соединения. Это избавит вас от огромных головных болей. Желательно, чтобы отправитель знал, какую версию поддерживает получатель.

• Если вы не отправляете данные в двоичном виде (изображения, звук), используйте читаемый текст в формате UTF-8. Это поможет устранить неполадки. Я бы придерживался JSON, но он не может быть оптимальным для вас. XML имеет высокие издержки.

• Если ваши сообщения достаточно длинные, вы можете попробовать сжать их с помощью известного алгоритма, такого как gzip (GZIPOutputStream).

Эти шаги, как вы можете видеть, способствуют открытости формата и слабой связи между вашим сервером и вашими возможными клиентами. Никто не знает, какую технологию будут использовать ваши клиенты в будущем: хотите сделать клиент для iPhone? клиент HTML5 + JS? То же самое для сервера:)

Answer 4

Для структурированных данных Xml JSon, вероятно, будет лучшим выбором. Однако для простых плоских записей я предлагаю вам рассмотреть CSV. Вы можете найти его проще / быстрее реализовать. Если у вас очень большое количество записей, ими легче управлять скважиной. например загрузить в электронную таблицу