Каков наилучший способ сохранения данных в приложении Java для настольных ПК? - PullRequest
10 голосов
/ 01 сентября 2008

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

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

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

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

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

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

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


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

  • База данных объектов - Обладает значительно меньшей инфраструктурой, чем подходы ORM, и работает быстрее, чем подход XML. спасибо аку

Ответы [ 6 ]

5 голосов
/ 01 сентября 2008

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

4 голосов
/ 01 сентября 2008

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

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

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

4 голосов
/ 01 сентября 2008

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

3 голосов
/ 01 сентября 2008

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

1 голос
/ 01 сентября 2008

XStream от codehaus.org

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

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

0 голосов
/ 02 сентября 2008

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

1) Незамедлительно заброшен! Я даже не буду оправдывать :)

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

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

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

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

...