Quelle est la meilleure façon de conserver les données dans une application de bureau Java ?

Question

J'ai une grande arborescence d'objets Java dans mon application de bureau et j'essaie de décider de la meilleure façon de les conserver sous forme de fichier dans le système de fichiers.

Voici quelques réflexions que j'ai eues :

• Lancez mon propre sérialiseur en utilisant DataOutputStream:Cela me donnerait le plus grand contrôle sur le contenu du fichier, mais au prix d’une microgestion.

• Ancienne sérialisation utilisant ObjectOutputStream et ses différentes classes associées:Cependant, je ne suis pas convaincu car je trouve les données fragiles.La modification de la structure d'un objet interrompt ses instances sérialisées.Je suis donc enfermé dans ce qui semble être un horrible cauchemar de versions.

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

• JavaDB:J'y avais pensé car 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 à la migration vers une architecture de serveur central si le besoin s'en fait sentir ultérieurement et introduit la possibilité d'interroger le modèle de données de manière plus simple.

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

---

Voici quelques options supplémentaires extraites des réponses ci-dessous :

• Une base de données d'objets - Possède beaucoup moins d'infrastructure que les approches ORM et fonctionne plus rapidement qu'une approche XML.merci aku

Answer 1

db4objets pourrait être le meilleur choix

Answer 2

J'opterais pour votre dernière option JavaDB (la distribution de Sun de Derby) et utilisez une couche relationnelle objet comme Hiberner ou iBatis.L’utilisation des trois premières approches signifie que vous passerez plus de temps à créer un moteur de base de données qu’à développer des fonctionnalités d’application.

Answer 3

Jetez un œil à Hibernate comme moyen plus simple de vous connecter à une base de données.

Answer 4

D'après mon expérience, il est probablement préférable d'utiliser une base de données intégrée.SQL, bien que loin d'être parfait, est généralement beaucoup plus simple que de concevoir un format de fichier performant et 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 demande un peu plus de travail en termes de déploiement.Cependant, il présente l’avantage de stocker l’intégralité de la base de données dans une seule bibliothèque multiplateforme.Fondamentalement, il s’agit d’un format de fichier générique préemballé.SQLite a été si utile que j'ai même commencé à l'utiliser à la place des fichiers texte dans les scripts.

Soyez prudent lorsque vous utilisez Hibernate si vous travaillez avec un petit problème de persistance.Cela ajoute beaucoup de complexité et de surcharge de bibliothèque.Hibernate est vraiment pratique si vous travaillez avec un grand nombre de tables, mais il sera probablement fastidieux si vous n'avez besoin que de quelques tables.

Answer 5

XStream de codehaus.org

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

Voir la présentation de mon groupe d'utilisateurs sur http://cjugaustralia.org/?p=61

Answer 6

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

1) Jeté immédiatement !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 conservera le graphique de données complet tel quel !Méfiez-vous de la durée pendant laquelle vous conserverez les objets persistants.Comme vous l'avez souligné, la gestion des versions peut être un problème.

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

4) Si vous devez de toute façon interroger vos données, restez fidèle à la solution DB.

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