Pattern MVC, partie Model et DAO

Bonjour a tous,

Je suis actuellement en train de me former sur les technologies JAVA/J2EE, et plus particulièrement pour les applications WEB.

Je créé un petit projet (un simple forum) afin de pouvoir mettre en place différents frameworks tel que spring, hibernate, struts, ...

Je connais bien le pattern MVC, mais néanmoins j'ai quelque petits problèmes avec l'architecture de mon application, notamment avec la partie model (donc indépendant du framework pour le moment).

Je souhaiterais dans un premier temps faire une connexion a une base de données via JDBC, ensuite la transformer en Hibernate, ensuite en EJB. Donc je pense utiliser soit le pattern factory, ou IOC (via Spring).

Jusqu'ici tout va bien. Le problème est que je ne sais pas comment faire une architecture qui sera PROPRE pour la partie model.
C'est a dire que je vais pouvoir accéder a mes DAO via des classes services, qui vont me retourner des objets beans (UserServices appelle UserDAO qui retourne UserBean). Sauf que ces objets ont des dépendances entre eux (un User possède une dépendance sur les Forum qu'il a créé) faut il que je charge tous les forums de l'utilisateur en même temps ? ( imaginons qu'un utilisateur ait créé un grand nombre de forum, et que je n'ai besoin seulement que de connaitre une information sur l'utilisateur, je vais donc charger la mémoire inutilement)

Je souhaiterais savoir si quelqu'un avait un ou plusieurs exemple de projet avec des sources, avec une bonne architecture, sur lesquels je pourrais m'appuyer ?

Si certaine partie de mon message ne sont pas claire, dites le moi, je reviendrais avec un diagramme de classe pour tenter d’être plus claire.

Je vous remercie d'avance pour l'aide que vous pourriez m'apporter :ccool:

Tu soulèves un problème plutôt récurrent lié à la profondeur des informations encapsulées dans une entité (au sens entity jpa).
En fonction de l'endroit d'où tu regardes, tu n'auras pas forcément besoin de toutes les informations.
Avec un système comme hibernate ou jpa, tu as la possibilité de déclarer un chargement tardif (lazy loading), ce qui permet de ne pas charger forcément tout le graphe d'objets, l'inconvénient vient lorsqu'on utilise les ejb et JTA (en standard). Dès qu'on sort du conteneur, les objets sont dit "détachés", plus moyen de faire du chargement tardif.
Une technique consiste à utiliser des DTO (Data Transfert Object), du coup, tu utiliseras un graphe de DTO correspondant exactement aux besoins d'une vue tout en utilisant un graphe d'entités commun.
Les DTO sont très décriés, personnellement, dans la configuration où on est (EJB, base de données AS400 qui date, ...), on l'utilise tout le temps (ou presque)

Bonjour OButterlin,

et merci de m'avoir répondu. J'ai effectué pas mal de recherche sur les DTOs pour en comprendre le fonctionnement.

Pour faire simple, ils permettent de personnaliser les objets et ainsi limiter le nombre de requêtes. Mais le problème sera la multitude de DTOs à créer en fonction des types de requêtes que l'on souhaite faire.

Pour être précis je vais donner un exemple dans mon cas (le projet forum):
J'ai 3 tables
User (id, login, password) //Utilisateur du forum
Forum (id, #User, titre, message) //Forum ouvert par un utilisateur
Talk (id, #Forum, #User, message) //Discution a un forum par un utilisateur

Si je créé les objets de cette table (Javabean) en admettant que user possède une collection de ses forums, et que forum possède une collection de ses talks. Si je n'utilise pas les DTOs, je risque très vite de charger beaucoup de données lorsque je vais vouloir juste rechercher des informations sur un utilisateur. (sans lazy loading pour le moment je travail juste en JDBC)

Exemple je veux juste la liste des utilisateurs, en gros je charge toutes la base de données :calim2:. Donc les DTOs seront ici un point fort puisque je devrais en définir un juste pour ne recevoir que l'id, le login et le mot de passe et pas la collection de ses forums (qui aurait inclus la liste des talks du forum et également chaque propriétaire des talks). De plus l’indépendance entre les couches est respectée.

Mais ce qui n'est pas apprécié avec les DTOs, ce sont les redondances de codes (car je vais surement avoir besoin de réécrire des paragraphes entier de codes qui se ressemble).
Mais sur le site de Sun, avec l'utilisation des DAOs, ils utilisent les DTOs si j'ai bien compris (lien).

Donc je voulais savoir si tout ce que je viens de dire au dessus est juste ?
Et si les DTOs ne sont pas appréciés, alors quels sont les autre méthodes que l'on peut utiliser pour respecter une indépendance entre les couches ? (et sans avoir besoin de charger toute la base de données si je veux juste lister les utilisateurs :mrgreen: ?

Oui, ce que tu dis est correct.
Mais le problème, c'est que ça devrait être la vue qui détermine les données à fournir, pas l'inverse.
Donc, en partant de la vue, tu construis le modèle objets (DTO) et tu récupère les données via une méthode spécifique dans ce qui deviendra plus tard une facade (en EJB).
Dans cette méthode, tu fais ce que tu veux, pour le moment en jdbc de 1 à n requêtes en fonction des besoins, plus tard via hibernate ou jpa en utilisant les relations one-to-many ou many-to-many en lazy loading.