Приложение Java Swing сохраняет пользовательский формат файла

Question

Я пишу несколько Swing-приложений (не богатых клиентов, работающих автономно) с большим количеством моделей доменов. Это Java Beans, связанные с пользовательским интерфейсом через модели презентаций.

Теперь мне нужно сохранить все данные домена в каком-то произвольном формате файла проекта.

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

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

Похоже, что более удачным подходом является использование спящего режима и его аннотаций для сохранения модели предметной области. Но какую базу данных я могу использовать для этого? Могу ли я получить проблемы с подключением к базе данных, потому что она не может быть полностью интегрирована (нет связи через порт на localhost => брандмауэры и т. Д.). Кроме того, сохранение некоторых файлов с использованием orm и базы данных в качестве промежуточного программного обеспечения в любом случае кажется немного раздутым.

Подводя итог: я относительно новичок в Java и сейчас программирую крупномасштабные свинговые приложения. У меня почти нет опыта работы с сериализацией (но у меня есть Effective Java : D), JPA и hibernate, доступные базы данных Java и т. Д.

Может кто-нибудь дать мне подсказку, пожалуйста? :)

Answer 1

Использование hibernate - хорошая возможность.

Некоторые встроенные базы данных существуют , поэтому вы можете запустить их при запуске приложения перед запуском гибернации.

Преимущество, конечно, состоит в том, что если вы когда-нибудь захотите преобразовать код из автономного в серверный режим, ваша модель java bean-hibernate-db также будет очень хорошо работать в этом контексте. Сериализация в ваш собственный формат - это все равно что создавать свою собственную базу данных с плоскими файлами, и зачем писать ее снова, когда она уже сделана для вас. Я также собирался предложить Apache Derby для встроенного использования (От: Java Drinker)

Для части миграции самый простой способ - это иметь в базе данных таблицу версий, сообщающую, какая версия является текущей, а затем при запуске приложения, после запуска базы данных, но до создания сеанса. Фабрика (или менеджер сущностей) проверяет текущую версию базы данных, проверяет в файле миграции sql последнюю версию и, если обе не совпадают, выполняет все запросы sql выше текущей версии базы данных.

Файл миграции может выглядеть так:

-- version:1
sql query 1 (update, alter, ...)

-- version:2
sql query 2

...

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

[редактировать]

• Первая часть импорта:

Если база данных не существует или является пустой (например, таблица версий отсутствует), вы начинаете с создания базы данных, а затем начинаете миграцию из старого формата в формат базы данных. Код будет выглядеть следующим образом: чтение старых файлов данных, создание экземпляров ваших объектов hibernate / jpa и сохранение их. (вы также можете написать более эффективный код для непосредственного создания SQL-запросов, но на это потребуется больше времени, и его будет намного сложнее поддерживать при изменении модели jpa)

• экспорт:

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

Answer 2

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

Управление версиями, вероятно, будет осуществляться с использованием XSLT для преобразования старых файлов сохранения в ихболее новые версии.На самом деле это было бы очень просто, так как я могу сохранить старый файл, сохранить новый файл и просто написать XSLT для разницы.

Answer 3

Используя JPA, вы можете сохранить всю информацию в любом формате JSON / XML / Excel / ODF, если используете DataNucleus в качестве реализации JPA (если данные, требующие сохранения, подходят для сохранения с использованием JPA).Зависит от данных, но из перечисленных форматов может подойти что-то вроде XML.

- Энди ( DataNucleus )