J'ai besoin de sauvegarder des objets - des instances de classes - dans mon application comme du type de fichier. Comment je peux écrire propre sérialiseur/désérialiseur pour cela?comment écrire propre sérialiseur/désérialiseur?
Ou existe un moyen plus facile comment enregistrer des objets à un type de fichier?
L'utilisation de io.serialization a été commentée comme n'étant pas une bonne solution pour une application "réelle". Pourquoi?
La sérialisation est difficile lorsque les objets changent (par exemple lorsque de nouveaux champs sont ajoutés). Les objets peuvent ne pas être initialisés comme vous le souhaitez ou peuvent manquer certaines données. Il existe des méthodes pour le faire, et la sérialisation personnalisée peut être implémentée en créant une méthode readObject et writeObject pour la désérialisation et la sérialisation. Des outils tels que XStream http://x-stream.github.io/ existent également pour la sérialisation vers XML. En fonction des données réelles que vous devez conserver, vous pouvez envisager d'écrire uniquement les données dont vous avez besoin, de les relire et de charger vos objets, plutôt que d'écrire les graphiques d'objets entiers via la sérialisation.
c'est une réponse intéressante. Je vais penser à ne sauvegarder que des données. – joseph
Avez-vous lu Discover the secrets of the Java Serialization API.
Il est plus ancien, mais couvre la plupart des choses de base.
Quelqu'un pourrait-il s'il vous plaît ajouter le nouveau lien de cet article? merci –
J'ai mis à jour le lien cassé. –
Essayez d'abord les mécanismes de sérialisation Java. Ils ne sont pas beaux, mais pour la plupart, ils feront le travail. Si vous rencontrez des problèmes spécifiques à l'aide des mécanismes intégrés, il peut être utile de rechercher une autre option. Il sont problèmes spécifiques avec les mécanismes de sérialisation de Java, mais ils n'ont pas d'importance pour la majorité des cas ...
Je vous recommande de lire this literature. Il décrit les différentes options pour sérialiser les objets avec des exemples pratiques.
«Le mécanisme par défaut, bien que simple à utiliser, n'est pas le meilleur. »
Le fichier java.io.Serializable est relativement facile à sérialiser. Il ne valide que contre serialVersionUID et ne vous permet pas de charger des versions plus anciennes/plus récentes de vos objets. Cela signifie que vous rendez invalide vos données sauvegardées avec des modifications significatives à vos objets.
Une autre approche consiste à enregistrer vos objets sous forme XML. Mais une telle implémentation peut devenir difficile car vous devez gérer des références de cercle. Vous pourriez mettre en œuvre quelque chose comme ce qui suit pour toutes les classes que vous souhaitez enregistrer:
public Element asXmlElement(Document doc) {
Element element = doc.createElement(this.getClass().getSimpleName());
element.setAttribute("class", this.getClass().getName());
element.setAttribute("id", this.getId().toString());
elements.put(this.getId(), element);
// add more properties here... either as child nodes or attributes!
// i.e. element.appendChild(referencedObj.asXmlElement(doc));
return element;
}
appel à cette méthode récursivement sur votre objet graphique peut éventuellement finir dans une boucle sans fin. Vous devez gérer cela (c'est-à-dire en gérant une liste de référence d'objets déjà gérés et en incorporant des éléments refID dans la structure XML).
En ajoutant un attribut de version à vos nœuds XML, vous pouvez gérer le chargement de différentes versions de vos données d'objet. Vous devez implémenter une sorte de classe exportateur/importateur capable d'utiliser ces méthodes. Bien sûr, vous avez besoin de la méthode opposée à asXmlElement ... quelque chose comme fromXmlNode (noeud Node) qui décode les données dans l'objet.
Ceci est seulement une approche possible.
Bonne réponse, mais il y a déjà quelque chose qui fait ce que vous décrivez, XStream: http://xstream.codehaus.org/ –
On dirait un joli cadre ... Je vais essayer. –
XStream peut-il gérer les entités persistantes? Je dois pouvoir réutiliser des entités déjà existantes définies par leur clé primaire. Ceux-ci doivent être mis à jour au lieu d'être créés lors du chargement du XML. Sinon, j'ai encore du travail à faire ... mais le cadre semble prometteur. –
"pas bon" dépend de l'exigence fonctionnelle. Dans certaines circonstances, c'est un choix parfait, dans d'autres circonstances c'est un mauvais choix. Si vous développez plus sur l'exigence fonctionnelle, alors nous pouvons donner des réponses mieux adaptées sur la «bonne» approche. – BalusC
Exigences fonctionnelles: Capable de sauvegarder un objet et de le charger (pas nécessairement enregistrer l'objet, mais éventuellement sauvegarder les champs de l'objet et le charger dans un nouvel objet). Fiabilité primaire, performance secondaire – joseph