2013-05-28 3 views
0

В настоящее время я реализую небольшую клиентскую базу данных на Java.Protobufs and Objects Java

Я моделирую транзакции с использованием объектов Java. Каждая транзакция содержит несколько утверждений и некоторые метаданные. Они передаются от клиента к серверу и обратно с использованием сокетов и сериализации Java. Затем они управляются в базе данных (например, обновляются их метаданные и т. Д.)

Я заметил, что собственная сериализация Java одновременно является узким местом, поэтому я хочу отойти от нее. Рассмотрев Kryo и ручной бенчмаркинг, я думаю, что Protobufs - хороший способ заменить сериализацию.

В настоящее время система принимает транзакции и утверждения, определенные как протобуферы.

Мой вопрос: эффективнее ли после получения protobuffer на стороне сервера создать обычный объект транзакции, изменить и использовать его, а затем заполнить новый protobuf для отправки обратно клиенту, или предпочтительнее работать непосредственно на protobuf (операции, которые я выполняю на транзакции на сервере, включают в себя обновление списков и т. д.)

Альтернативно, было бы предпочтительнее использовать Kryo для такого использования?

+1

Ваш вопрос трудно понять –

+0

Отредактировано с учетом того, что – user1018513

ответ

0

Я подозреваю, что в конечном итоге вы обнаружите, что у вас есть собственные бизнес-объекты, в которых ваш код в основном работает, и сохранение protobufs в коде inteface будет работать лучше всего для вас.

Это мой опыт. Зачем?

Во-первых, вы не получаете никаких конкретных спецификаций protobuf или артефактов в бизнес-объектах. Это облегчает отладку при возникновении проблемы в бизнес-коде, поскольку вы можете исключить любые ошибки, вызванные кодом protobuf, которого нет. Кроме того, эти бизнес-классы не будут импортировать какие-либо материалы protobuf, которые упрощают работу.

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

Оба эти могут быть сведены к лучшему разделению проблем, лучшей изоляции компонентов системы и лучшей герметизации.

+0

Я согласен - разделение классов объектов домена с классами сопряжения/передачи данных является хорошей вещью, и это не требует больших затрат на гибкость, которую вы получаете. – pjklauser