Bonjour,

Je réalise dans le cadre de mes études un projet J2EE, notre premier projet J2EE, qui mets en oeuvre les choses suivantes:
un client léger (struts tomcat)[machine 1], un service web[machine 1] et un client lourd(swing)[machine 2] qui tous trois font appel via RMI à des POJO[machine 3](respectant les conventions javabean) persistés avec hibernate 3.2.5 dans une base mysql[machine 4].

Cette architecture a été choisie avec le peu de recul que nous avions , mais bref.

Nous avons organisé cela de la manière suivante (là encore avec notre recul limité):
Un projet Metier contenant:
  • Un package domaine avec les pojos (A B C)
  • Un package service (ServiceA, ServiceB, ServiceC et leurs interfaces) pour proposer quelques méthodes métier sur les classes du domaines
  • Un package dao (DaoA DaoB DaoC et leurs interfaces) qui est utilisé uniquement par les Services. Dans DAO, chacune de nos méthodes ouvre et ferme la session, donc rien n'est fait en dehors du DAO à propos des sessions.
  • Un package rmi avec un unique serveur RMI (est-ce une bonne chose ?) qui fait appel quasiment directement à chacune des méthodes des différents Services et qui est le seul point d'accès des vues à la couche métier.
  • Un package junit avec nos tests unitaires.

Des projets appliLourde, appliWeb, et webService.

J'ai lu le thread http://www.developpez.net/forums/sho...d.php?t=343249, mais d'une part, j'ai manqué de détail pour être capable d'appliquer les idées qui s'y trouvent, et d'autre part, je ne sais pas si cela s'applique toujours quand RMI viens s'en mêler.

Le problème classique
On pensait se débrouiller pas mal, ayant réussi à faire une appli lourde permettant d'ajouter/supprimer/lister des objets simples (sans relations à d'autres objets) en base, cela s'est compliqué pour faire la même chose avec un objet ayant une référence vers un autre objet qui mène à l'erreur "LazyInitializationException" (en réalité, c'est dans l'affichage de la liste de ces objets, que la méthode toString fait appel aux références et que celles-ci n'ont vraisemblablement pas été chargées bien qu'aucun lazy=true ne figure dans nos fichiers de mapping).

Après m'être une peu renseigné, j'ai abouti aux conclusions suivantes
  • Il n'est pas possible de maintenir la session jusqu'à ce que la vue soit finie de charger

    What about three-tier environments?

    It's clear that this pattern only makes sense if you can actually use a local Session when rendering the view. In a three-tier environment the view might be rendered on the presentation virtual machine, not on the service virtual machine with the business and data access layer. Therefore, keeping the Session and transaction open is not an option. In this case you have to send the right "amount" of data to the presentation layer, so a view can be constructed with the Session already closed. It depends on your architecture if you better use Detached Objects, Data Transfer Objects, or maybe a mix of both with the Command Pattern. These options are discussed in Hibernate in Action.

    source: http://hibernate.org/43.html
  • L'idéal pour moi était pourtant de pouvoir garder le lazy-loading à distance afin de ne pas avoir à prévoir ce dont le client a besoin, mais apparemment les POJOS ne seraient pas fais pour ça (cf. http://www.developpez.net/forums/sho...=rmi+hibernate)
  • Il faut donc charger toutes les infos dont l'interface a besoin. Mes objets domaine étant très liés entre eux, j'aurai je pense vite fait de charger tout le graphe objet si je n'y fait pas attention (même si c'est un projet d'étude, donc les données ne sont pas très volumineuses).

Si mes conclusions sont correctes, ma question est donc: Y a-t-il un moyen élégant de charger uniquement les objets nécessaires à la vue, sachant que certaines méthodes (listAll par exemple) peuvent être appelées à des fins différentes et donc ne pas nécessiter les mêmes informations.

J'ai du mal à me résoudre à créer une méthode pour chaque usage ou bien à passer des options en paramètres..
J'aurai donc besoin d'un petit coup de pouce à ce niveau là .

Merci beaucoup pour votre aide.