juillet
2008
Un article de morgoth_fr
Pour mon premier billet, je vais parler du problème qui me préoccupe depuis que je suis à la recherche du framework JEE « idéal » : la gestion des objets au travers des couches de l’application.
Dans les temps anciens, un POJO n’était qu’une sorte de struct (comme en C) permettant de stocker des infos. Ces infos viennent généralement de la BD, et sont utilisées dans la couche métier, dans la couche présentation, puis éventuellement retournent en BD.
Avec Hibernate, il est très tentant de créer des POJO représentants les objets métier et de les persister en BD directement (pas de DAO). Il suffit même de mettre de jolies annotations dans le POJO !!
Avec Tapestry 5, il est très tentant d’utiliser directement les POJO métier pour générer des formulaires et des tables de CRUD (pas de DTO). On ajoute donc les annotations Tapestry dans le POJO métier ??? C’est ici que je me suis arrêté, me doutant que ça n’allait pas bien marcher.
En effet, bien souvent, on ne veut pas toutes les informations en même temps (par exemple selon les droits d’une personne, toutes les infos d’un objet ne sont pas affichées). Le problème des annotations est qu’on ne peut en ajouter/enlever dynamiquement (à ma connaissance). Par exemple, si je mets l’annotation @Required sur l’attribut « nom » de ma classe « Personne », ce champ sera tout le temps requis dans tous les pages Web où je vais l’utiliser.
J’arrive donc à la conclusion qu’il faut au minimum 2 couches d’objets : un objet de présentation, et un objet métier/dao (pour le moment ça ne m’a pas posé de problème). La nécessité d’avoir un objet de présentation dédié n’est pas propre à Tapestry 5. Cherchez sur le net GWT + Hibernate, et vous verrez que le sujet est brulant.
Bon, sauf que dans 90% des cas, mon objet de présentation va beaucoup ressembler à l’objet métier (avec peut-être quelques champs en plus ou en moins). De plus, je vais passer mon temps à faire des copie d’attributs dans les deux sens (ce qu’est sensé faire le framework Dozer).
Un autre cas très concret. Souvent, l’objet métier contient beaucoup trop de champs pour être remplis avec un seul formulaire. On utilise alors une succession de pages (wizard) pour remplir petit à petit toutes les informations.
Ce que j’aimerais, c’est pouvoir exprimer ce découpage avec des objets.
Par exemple, prenons un objet métier « Personne ». Cet objet possède les champs : nom, prénom, téléphone, adresse, age
Je veux découper la saisie en 3 étapes :
1) Saisir le nom+prénom
2) Saisir téléphone + adresse
3) saisir l’age
Avec Tapestry 5, je peux générer un formulaire et tout le traitement/validation associé à partir d’un objet, donc je vais avoir les objets :
PersonneWizStep1
PersonneWizStep2
PersonneWizStep3
Les champs nom et prénom de l’objet PersonneWizStep1 vont correspondre exactement aux champs nom et prénom de mon objet « Personne ».
Solution 1 : faire de la recopie avec Dozer (pas top)
Solution 2 : créer un objet NomPrenom qui va remplacer l’objet PersonneWizStep1 et qui sera un composant (au sens Hibernate) de l’objet Personne. Mais bon, on retrouve le même problème. Si en fonction des droits, je veux pouvoir saisir uniquement le nom et pas le prénom (exemple stupide je sais), il me faudrait un autre objet pour y mettre des annotations différentes.
Bonjour,
Je suis dans le même esprit de recherche du meilleur framework j2ee
et je me suis attardé sur Tapestry 5. J’ai un peu ce même problème
à comprendre comment ça peut fonctionner juste avec des pojos.
Si par exemple j’ai besoin d’une variable commune à toutes les pages (titre du site)
dans quelle classe je mets ça? j’ai un peu de mal
Bonjour,
Sujet super intéressant
Sinon, j’aurais un petit point à soulever:
Utilser les annotations JPA sur les PAOs (Persistent Anemic Object, terme plus précis que POJO dans ce cas de figure), ne veut aucunement dire que l’on a plus de couche DAO. Il faut que tu crées toi même des DAOs basés sur l’entityManager où la Session d’Hibernate, ou encore utiliser directement ces objets (EM ou Session) en tant que DAO-like dans la couche service (ce qui ne me plaît pas du tout).
Bref, les DAOs sont toujours là.
Hello,
Il y a du avoir un loupé.. il manque une phrase à la fin de ce paragraphe :
En effet, bien souvent, on ne veut pas toutes les informations en même temps (par exemple selon les droits d’une personne, toutes les infos d’un objet ne sont pas affichées). Le problème des annotations est qu’on ne peut en ajouter/enlever dynamiquement (à ma connaissance). Par exemple, si je mets l’annotation @Required sur l’attribut « nom » de ma classe « Personne », ce champ sera tout le temps requis dans tous les pages Web où je vais l’utiliser. Même problème avec
@++