>
Définition
La durée de vie d'un objet (au sens informatique du terme)
peut dans certains cas correspondre au besoin de celui-ci d'exister
au delà du temps d'exécution du programme qui l'a créé,
l'adresse de l'objet "dans l'espace" pouvant changer par
rapport à son adresse de création. La persistance est ainsi le fait
"d'exister dans le temps". Un objet qui reste en l'état
quand il est sauvegardé puis chargé par une autre application,
ou à un moment éloigné, possède la propriété
de persistance. En conséquence, l'objet n'est plus dépendant
de l'application qui l'a créé.
> Pourquoi ?
La logique des ordinateurs veut qu'un objet ne puisse survivre à
son créateur: un programme que l'on ferme perd les informations
qui y sont entrées, un ordinateur que l'on éteint perd les
données stockées dans sa mémoire vive. Pourtant,
la persistance se révèle obligatoire pour des applications
où l'information doit transiter d'une application à
une autre, ou être accessible (et inchangée) à
n'importe quel moment. On obtient ce résultat en faisant
une sauvegarde des données.
> Spécificités
Il en est autrement dans la logique "tout objet", où
l'on préfère déclarer un objet comme persistant,
le reste étant pris en charge automatiquement (selon le langage
utilisé). L'objet persistant ne faisant pas référence
à un fichier, il faut sauver sur le disque la classe avec
l'objet. Il est quasiment nécessaire de passer alors par
une base de données objet.
> SGBD relationnel ou objet ?
En effet, si un SGBD relationnel peut suffire quand le nombre d'objets
persistants est faible, les performances s'écrouleront si
l'on doit travailler avec un très grand nombre d'objets,
comme c'est rapidement le cas dans les applications d'envergure.
Le SGBD objet permet non seulement
de faciliter une interface propre avec le langage de programmation,
mais surtout d'être (le plus souvent) bien plus rapide que
son homologue relationnel, tout en conservant la flexibilité
de ce dernier dans l'implémentation rationnelle en termes
d'évolution de schéma.
Il faut cependant bien reconnaître
que les bases de données relationnelles sont encore la technologie
de stockage prédominante de nos jours. Le problème
revient donc à construire une sorte de "pont" entre
ces deux logiques.
> Rapprochements
Le concept de persistance est fortement lié à celui
de sérialisation d'objet en Java, et n'est pas à
rapprocher de celui des sessions (comme en PHP - en effet, l'objet
est perdu entre deux sessions...).
Par ailleurs, la persistance renvoie à une série de composants qui,
au sein d'un serveur d'applications, assurent les liens entre les
objets métier relatifs à la couche applicative de la solution et
les données qui lui sont associées au sein de la base de données
sous-jacente.
> Persistance & plates-formes
J2EE propose depuis longtemps un modèle de composants prédéfinis
(les EJB Entities) conçu pour faciliter la mise au point de cette
couche de persistance. L'équivalent des EJB Entities pour .Net est
encore en chantier. Nom de code: Objectspaces. Ces deux environnements
sont-ils aussi performants sur ce terrain ? C'est difficile à dire...
Sur ce sujet, les débats vont bon train parmi les développeurs.
Il semble en tous cas que les modèles pré-définis, tels que les
EJB, ne soient pas toujours à la hauteur des performances attendues.
|
[