Le pattern
transfer Object précédemment appelé
Value Object est une classe implémentant l'interface
Serializable.
Ce pattern est essentiellement utilisé pour échanger des données entre une application cliente et des
EJB de type
Entity (
EntityBean).
Pourquoi me direz-vous?
Tout simplement parce que, comme vous le savez, les EntityBean comme tous les EJB sont des objets distants, ce qui induit, pour chaque accès à celui-ci, un aller-retour à travers le réseau, avec en plus démarrage/validation de transactions.
Par exemple, pour lire un objet Personne avec 5 attributs, il vous faudra 6 allers-retours pour récupérer vos informations (1 findByPrimaryKey + 5 lectures d'attribut).
C'est pour cette raison que les
Transfer Object sont là.
les EntityBean ne sont là que pour être utilisé sur le serveur EJB (dans les EJB 2.0, ils sont maintenant "local", ils ne peuvent pas être accessible de l'exterieur). L'idée est de fournir un service avec des EJB stateless qui vont vous fournir les service qui vous intéressent (Lecture/création/modification/suppression ... d'un objet). Cet EJB utilise des Entity en interne pour faire les opérations, et créer des classes de transport (avec uniquement les attributs + get/set), cette classe doit implémenter
Serializable pour pouvoir passer sur RMI/IIOP. C'est cette classe que l'on appelle
Transfer Object
L'avantage de ce modèle, c'est avoir une programmation distante (N tiers) avec le transit de veritables objets que vous allez pouvoir manipuler puis renvoyer au serveur pour modification... .
Voici un petit exemple qui venir étayer la partie théorique.
Entity Bean
L'interface Home L'avantage avec cette solution (EJB + VO) c'est que l'accès et les régles de gestion sont centralisés sur un seul serveur. Si une autre application (back office) ou un autre serveur web, veut accèder à la même information, il pourra réutiliser tout cela.