Как лучше всего сохранять данные в настольном приложении Java?

У меня есть большое дерево объектов Java в моем настольном приложении, и я пытаюсь решить, как лучше всего сохранить их в виде файла в файловой системе.

Вот некоторые мысли, которые у меня были:

  • Сверните мой собственный сериализатор с помощью DataOutputStream: Это дало бы мне максимальный контроль над тем, что находится в файле, но за счет микроуправления им.

  • Прямая старая сериализация с использованием ObjectOutputStream и различных связанных с ним классов: Мне это не нравится, потому что я считаю данные хрупкими. Изменение структуры любого объекта разрушает его сериализованные экземпляры. Так что я заперт в ужасном кошмаре управления версиями.

  • XML-сериализация: Это не так хрупко, но значительно медленнее, чем прямая сериализация. Его можно преобразовать вне моей программы.

  • JavaDB: Я подумал об этом, так как мне комфортно писать приложения JDBC. Разница здесь в том, что экземпляр базы данных будет сохраняться только во время открытия или сохранения файла. Это некрасиво, но ... он позволяет перейти на архитектуру центрального сервера, если в этом возникнет необходимость, и предоставляет возможность более простого запроса модели данных.

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


Вот еще несколько вариантов, взятых из ответов ниже:

  • База данных объектов - имеет значительно меньшую инфраструктуру, чем подходы ORM, и работает быстрее, чем подход XML. спасибо, аку
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
В компьютерном программировании биты играют важнейшую роль в представлении и манипулировании данными на двоичном уровне. Побитовые операции...
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Приходилось ли вам сталкиваться с требованиями, в которых вас могли попросить поднять тревогу или выдать ошибку, когда метод Java занимает больше...
Полный курс Java для разработчиков веб-сайтов и приложений
Полный курс Java для разработчиков веб-сайтов и приложений
Получите сертификат Java Web и Application Developer, используя наш курс.
10
0
3 685
6
Перейти к ответу Данный вопрос помечен как решенный

Ответы 6

Взгляните на Hibernate как на более простой способ взаимодействия с базой данных.

XStream с сайта codehaus.org

Сериализация / десериализация XML в основном без кодирования. Вы можете использовать аннотации, чтобы настроить его. Хорошо работаю в двух проектах, над которыми работаю.

Посмотреть презентацию моей группы пользователей на http://cjugaustralia.org/?p=61

Я бы выбрал ваш последний вариант JavaDB (дерби от Sun) и использовал объектно-реляционный уровень, такой как Спящий режим или iBatis. Использование первых трех подходов означает, что вы потратите больше времени на создание ядра базы данных, чем на разработку функций приложения.

Ответ принят как подходящий

db4objects может быть лучшим выбором

По моему опыту, вам, вероятно, лучше использовать встроенную базу данных. SQL, хотя и не идеален, обычно намного проще, чем проектировать хорошо работающий и надежный формат файла.

Я не использовал JavaDB, но мне повезло с H2 и SQLite. SQLite - это библиотека C, что означает немного больше работы с точки зрения развертывания. Однако его преимущество заключается в том, что вся база данных хранится в единой кроссплатформенной библиотеке. По сути, это предварительно упакованный общий формат файла. SQLite оказался настолько полезным, что я даже начал использовать его вместо текстовых файлов в сценариях.

Будьте осторожны при использовании Hibernate, если вы работаете с небольшой проблемой постоянства. Это добавляет сложности и накладных расходов на библиотеку. Hibernate действительно хорош, если вы работаете с большим количеством таблиц, но, вероятно, он будет громоздким, если вам нужно всего несколько таблиц.

Я думаю, это зависит от того, что вам нужно. Посмотрим варианты:

1) Снято немедленно! Я даже не буду оправдываться. :)

2) Если вам нужна простая, быстрая настойчивость с использованием одного метода, придерживайтесь ее. Он сохранит полный график данных как есть! Остерегайтесь того, как долго вы будете обслуживать сохраненные объекты. Как вы отметили, управление версиями может быть проблемой.

3) Медленнее, чем (2), требуется дополнительный код и может редактироваться пользователем. Я бы использовал его только в том случае, если данные должны использоваться клиентом на другом языке.

4) Если вам все равно нужно запросить данные, придерживайтесь решения БД.

Что ж, думаю, вы уже ответили на свой вопрос :)

Другие вопросы по теме