Quel est le meilleur moyen de conserver les données dans une application Java Desktop?

Question

J'ai un grand arbre d'objets Java dans mon application de bureau et j'essaie de décider de la meilleure façon de les conserver en tant que fichier dans le système de fichiers.

Quelques réflexions que j'ai eu étaient:

• rouleau mon sérialiseur en utilisant DataOutputStream: Cela me donnerait le plus grand contrôle de ce qui était dans le dossier, mais au prix de microgestion il.

• Straight old Sérialisation avec ObjectOutputStream et ses différentes classes associées: Je ne suis pas vendu car je trouve les données cassantes. La modification de la structure d'un objet casse les instances sérialisées de celui-ci. Donc, je suis enfermé dans ce qui semble être un cauchemar horrible versioning.

• Sérialisation XML: Ce n'est pas aussi fragile, mais il est nettement plus lent que la sérialisation. Cela peut être transformé en dehors de mon programme.

• JavaDB: Je l'ai considéré puisque je suis à l'aise pour écrire des applications JDBC. La différence ici est que l'instance de base de données ne persisterait que pendant l'ouverture ou l'enregistrement du fichier. Ce n'est pas joli mais ... il se prête bien à la migration vers une architecture de serveur centrale si le besoin s'en fait sentir plus tard et il introduit la possibilité de modifier le modèle de données d'une manière plus simple.

Je suis curieux de voir ce que les autres pensent. Et j'espère avoir manqué une approche évidente et plus simple que celles ci-dessus.

---

Voici quelques plus d'options puisés dans les réponses ci-dessous:

• une base de données objet - a considérablement moins d'infrastructures que ORM approches et exécute plus rapidement qu'une approche XML. merci aku

Answer 1

db4objects pourrait être le meilleur choix

Answer 2

Jetez un coup d'œil à Hibernate comme un moyen plus simple de s'interfacer avec une base de données.

Answer 3

XStream de codehaus.org

sérialisation XML/désérialisation en grande partie sans codage. Vous pouvez utiliser des annotations pour le modifier. Je travaille bien dans deux projets où je travaille.

Voir mes utilisateurs présentation du groupe à http://cjugaustralia.org/?p=61

Answer 4

Je pencherais pour la dernière option JavaDB (la distribution de Sun de Derby) et utiliser une couche relationnelle objet comme Hibernate ou iBatis. En utilisant les trois premières approches, vous allez consacrer plus de temps à la construction d'un moteur de base de données qu'à développer des fonctionnalités d'application.

Answer 5

Dans mon expérience, vous êtes probablement mieux d'utiliser une base de données intégrée.SQL, bien que moins que parfait, est généralement beaucoup plus facile que de concevoir un format de fichier qui fonctionne bien et qui est fiable.

Je n'ai pas utilisé JavaDB, mais j'ai eu de la chance avec H2 et SQLite. SQLite est une bibliothèque C ce qui signifie un peu plus de travail en termes de déploiement. Cependant, il a l'avantage de stocker toute la base de données dans une seule bibliothèque multiplateforme. Fondamentalement, c'est un format de fichier générique pré-emballé. SQLite a été si utile que j'ai même commencé à l'utiliser au lieu de fichiers texte dans les scripts.

Faites attention en utilisant Hibernate si vous travaillez avec un petit problème de persistance. Cela ajoute beaucoup de complexité et de surcharge de la bibliothèque. Hibernate est vraiment sympa si vous travaillez avec un grand nombre de tables, mais il sera probablement encombrant si vous n'avez besoin que de quelques tables.

Answer 6

Je pense que cela dépend de ce dont vous avez besoin. Voyons les options:

1) Descarded imediatelly! Je ne vais même pas justifier. :)

2) Si vous avez besoin d'une persistance simple, rapide et à une seule méthode, respectez-la. Il va persister le graphe de données complet tel qu'il est! Méfiez-vous de combien de temps vous allez maintenir les objets persistants. Comme vous l'avez souligné, la gestion des versions peut être un problème.

3) Plus lent que (2), nécessite un code supplémentaire et peut être modifié par l'utilisateur. Je ne l'utiliserais que si les données sont supposées être utilisées par un client dans une autre langue.

4) Si vous avez besoin d'interroger vos données de toute façon, respectez la solution DB.

Eh bien, je pense que vous avez déjà répondu à votre question :)