[EMF] [eCore] [proxy] [persist] [lazy loading scheme]

Bonjour,
Je fais mes premiers pas en EMF, pour cela j'ai commencé par lire un bon tutoriel qui est d'ailleurs celui-ci : EMF Framework Programmer's Guide --> EMF developer guide --> Programmer's guide --> EMF framework programmer's guide.
et quand je suis arrivé à la partie One-way references, là je n'ai pas bien compris quelques concepts.
J'ai quelques questions à vous poser à propos, et je vous prie de bien vouloir me répondre.
1) ...including the type of author, needs to deal with the possibility that the referenced object (in this case Writer) may persist in a different resource (document)
from the source object (in this case Book)... quel est l'intêret de chercher tous les objets référencé à partir de l'objet source?
2) qu'est ce qu'on veut dire par ce mécanisme : lazy loading scheme?
3) qu'est ce qu'on veut dire par proxy for the object? et pourquoi on l'utilise?

Et une dernière question fondamentale à vous poser, c'est quoi la différence entre eCore et EMF?

Merci d'avance.

Bonjour,

Là je reviens et je réponds à moi même, et j'espère que ça pourra utile pour les autres.
Je m'adresse à l'administrateur de ce forum, si ce topic ne correspond à ce forum, prière de m'indiquer le forum adéquat.

1) Je commence par expliquer la notion de ressource: Un besoin qui arrive toujours est celui de stocker un modèle. Dans le cas d'EMF ça se fait par défaut dans un document XML. Il est cependant possible d'utiliser d'autres formats, ou même de ne pas le faire dans un fichier mais par exemple dans une base de données.
C'est pour ça que EMF utilise le terme plus général de "ressource". Une ressource EMF est donc un élément qui permet de persister un modèle.
Avec EMF, il est possible de ne pas mettre tout le modèle dans la même ressource, mais de stocker certains parties dans une ressource est d'autres parties dans une autre ressource. Dans le cas du tutoriel on peut vouloir par exemple avoir un document XML avec l'information de tous les livres et un autre document XML avec l'information des écrivains.

C'est dans ce cas là que la gestion des références se complique. Supposons que je stocke l'information des livres dans un fichier XML, et l'information des écrivains dans un autre fichier XML, maintenant je veux faire un petit programme pour afficher la liste des livres avec le nom de leurs auteurs, d'abord je charge le document des livres et je prend chaque livre (une instance de Book), à travers laquelle je navigue la référence author (en appelant la méthode Book.getAuthor) pour avoir le nom de l'auteur. Mais puisque l'information sur les écrivains se trouve dans une autre ressource, il faut charger le document XML des livres et aller charger l'objet Writer correspondant. Pareil quand je sauvegarde. Si je crée un nouveau livre et je renseigne son auteur, maintenant il faut sauvegarder les deux documents, et un plus dans le fichier des livres il faut se souvenir pour chaque référence dans quel ressource est stocké l'objet destination et son identité.
Tout cela est géré par EMF d'une manière transparente au développeur.

L'intérêt d'EMF est qu'on peut naviguer dans tous les modèles sans se soucier où sont stockées les informations (dans un seule fichier,dans plusieurs fichiers, dans un base de données, une partie dans un fichier une autre dans un base de données, etc ),tout ce qu'il faut faire c'est de suivre les références en utilisant les méthodes get/set générées.

2) Si on a un modèle d'une taille volumineuse et qu'on l'a découpé en plusieurs ressources, le code généré par EMF ne charge pas tout en mémoire d'un seul coup, mais il va charger les différentes ressources à la volée en fonction de la navigation qui fait mon programme. Donc ça permet de réduire la consommation mémoire quand on manipule un modèle.

3) C'est l'implémentation du mécanisme de Lazy-loading. Lorsque EMF charge un objet à partir d'une ressource, il regarde toutes ses références, si l'objet de destination se trouve dans la même ressource alors il lit toute l'information correspondante; si l'objet destination se trouve dans une autre ressource, il ne charge pas la ressource destination (c'est ce qui permet de réduire l'empreint mémoire) .. mais il doit toutefois se souvenir de la ressource de destination et de l'identité de l'objet destination, cette information est stockée par EMF dans un objet proxy qui représente la destination. Si mon programme ne navigue jamais dans cet objet, alors tout ce qu'il y aura en mémoire c'est l'adresse de la destination.

Cordialement,