Стратегия постоянства для автономного настольного Java-приложения - PullRequest
3 голосов
/ 01 марта 2012

(Мне удалось найти еще один вопрос по этому вопросу - Стратегия сохранения объектов для настольного приложения )

У меня есть базовое приложение Java Swing - которому нужно получить доступ / сохранить несколько тысячPOJOs.Мне может потребоваться выполнить базовые запросы к ним.

Изначально я посмотрел JPA-Hibernate + HSQLDB, но это замедляет время запуска приложения, и я решил, что для моих запросов это было излишним.

Я упростил свою модель данных и начал изучать БД документов - mongodb - это здорово, но он не очень подходит для несерверных сред;запуск и остановка процесса mongod из Java (с использованием ProcessBuilder) - это очень сложно, и я действительно хочу встроенное решение.

Мне очень нужен быстрый и легкий инструмент персистентности с базовыми функциями запросов, который можно встроить в Javaприложение.

Это единственные опции?

  • http://prevayler.org/
  • Встроенная база данных Java (HSQL) без ORM
  • Сериализация Java в файловой системе
  • JSON сохраняется для плоских файлов?
  • XStream (и XBird? - http://code.google.com/p/xbird/)
  • OODB
  • Реализация JCR?

Может ли кто-нибудь предложить какие-либо другие советы / предложения? В какой момент сериализация большого списка POJO начнет реально снижать производительность?

Спасибо

edit: Только что нашел этот пост - https://stackoverflow.com/questions/2825491/are-there-any-embeddable-document-database-engines-for-java-something-similar-t рекомендация Orient - http://code.google.com/p/orient/

Ответы [ 3 ]

1 голос
/ 02 марта 2012

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

1 голос
/ 02 марта 2012

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

public interface DocumentRepository {
    public Document create();
    public Document load(String id);
    public void update(Document doc);
    public Set<Document> findByCustomerNameFreeTextSearch(String query);
}

Это должно быть реализовано поверх множества бэкэндов.

Во-вторых, я бы изначально реализовал это с простой старой сериализацией. Что-то вроде:

public class SerializingDocumentRepository implements DocumentRepository {
    private final File persistenceDir;

    public Document create() {
        return new Document();
    }

    public Document load(String id) {
        ObjectInputStream in = new ObjectInputStream(persistenceDir, new File(id));
        try {
            return (Document)in.readObject();
        }
        finally {
            in.close();
        }
    }

    public void update(Document doc) {
        ObjectOutputStream out = new ObjectOutputStream(persistenceDir, new File(id)).writeObject(doc);
        try {
            out.writeObject(doc);
        }
        finally {
            in.close();
        }
    }

    public Set<Document> findByCustomerNameFreeTextSearch(String query) {
        Set<Document> hits = new HashSet<Document>();
        for (String filename: persistenceDir.list()) {
            Document doc = load(filename);
            if (doc.getCustomer().getName().contains(query)) hits.add(doc);
        }
        return hits;
    }
}

Только с обработкой исключений.

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

1 голос
/ 01 марта 2012

Недавно я использовал db4o (http://www.db4o.com/) в качестве хранилища данных для автономного настольного приложения. Это база данных объектов, которую можно запускать во встроенном режиме без сервера, работающего в фоновом режиме.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...