Discussion :

[johan_b]

Bonjour à tous, je me pose une petite question concernant un developpement "propre" d'un appli struts.

Pour avoir un modèle MVC (ou plutot MV2C) propre, j'avais pensé à faire ceci:
Utiliser des classes métiers:
par exemple une classe utilisateur qui accèdent à une base de donnée et récupèrent les informations précises.
Les beans: qui contiennent les seules infos necessaires, avec uniquement des méthodes get et set. (ex: userBean)
Les struts actions: un action pour se logger instanciera un Utilisateur (à partir de son login récupéré dans un bean reçu par exemple), récupèrera les infos necessaires sur ce dernier (par appel à ses méthodes) et crée un bean de retour userBean avec ses informations qu'il renvoie aux vues.
Les vues:
ex: une vue qui utilise le bean userBean et affiche les résultats attendus.

En gros jaurrais ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
class Utilisateur extends ClasseMetier{
public Utilisateur ("login"){
 //connexion à la bd et recup des infos
}
public getNom(){rreturn nom);
}
 et à partir de ma struts action faire:
String login = (String)actionForm.get("login");
Utilisateur monUtilisateur= new monUtilisateur(login);
userBean  ubean= new userBean ();
ubean.setNom(monUtilisateur.getNom());
session.setAttribute("userInfo", ubean);
return (mapping.findForward("success"));

Donc j'aimerais avoir votre avis sur cette méthode, étant encore novice en la matière.

Par contre, je me demande si on crée le bean de retour (userBean) dans la struts action (en faisiant par exemple userBean.setNom(Utilisateur.getNom()) ) ou dans la classe métier, en utilisant par exemple une méthode renvoyant l bean créé:
ex:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
class Utilisateur extends ClasseMetier{
public userBean getuserBean(){
 userBean bean = new UserBean();
  bean.setNom(this.nom); 
bean.setInfo...(this.nom); 
  return bean;
}
}
 et à partir de ma struts action faire:
String login = (String)actionForm.get("login");
Utilisateur monUtilisateur= new monUtilisateur(login);
userBean  ubean= monUtilisateur.getUserBean);
session.setAttribute("userInfo", ubean);
return (mapping.findForward("success"));

Si javais directement créé le bean userBean à partir de mes struts Actions (donc en faisant les requetes SQL à partir des Actions), je ne pense pas que ça soit très propre (redondance de code pour acceder aux données, grosses modifs à faire en cas de changement de bas ou autre).

edit: on dit toujours de moi que je ne susi jamais assez clair,alors n'hésitez pas à demander plus de précisions

[djo.mos]

Bonjour.
pour l'effort et le respect du MVC !

Sinon, en ce qui concerne la couche métier, ce que dont tu parles est le pattern DTO/DAO :
- DTO : Data Transfer Object en gros un POJO (getXXX et setXXX) et qui comme son nom l'indique sert à transférer les données entre les couches de l'application
- DAO : Data Access Object : des classes qui manipulent les DTO, càd qu'ils les chargent de la BD, qu'ils les persistent, les suppriment, etc.


en gros, tous tes DAOs auront en commun cette structure :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
public Interface GenericDao<T, ID>{
  public List<T> findAll();
  public T findById(ID id);
  public void delete(T entity);
  public void update(T entity);
  public T add(T entity);
}

Et tu peux ajouter d'autres méthodes au besoin.
Dans ton cas par exemple, on peut définir le DTO du User comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
public class User {
  private Long id;
  private String login;
  private String pwd;
 
  //Les getters + les setters
 
}

et ton UserDao :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
public class UserDao implements GenericDao<User, Long> {
  //implémentes les méthodes du généric Dao
 
  //Tu peux ajouter cette méthode
  public List<User> findByExample(User u){
  ..."SELECT * FROM user WHERE login=u.getLogin() AND pwd=u.getPwd()"...
  }
}

La méthode qu'on a ajouté, findByExample, peut servir dans l'action LoginAction : ici un exemple d'execute()

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
User u = new User();
u.setLogin(form.getLogin());
u.setPwd(form.getPwd());
List<User> res = (new UserDao()).findByExample(u);
if(res.size()==0)
  return mapping.findForward("failure");
else
  return mapping.findForward("success");

Bref, j'espère que tu a compris le principe !

[johan_b]

je vois à peu près le truc oui.

Donc si j'ai bien compris jaurrais 4 types de classes:

1)Les actionForm étant les bean contenant les données transmises par les formulaires et utilisés par mes struts Action

2)Les struts Action qui prennent ce quil ya dans les bean et créent les DTO
A partir de ça on renvoie vers une vue qui utilise ces DTO (si seulement besoin d'afficher les infos ransmises par formulaire) ou demandent aux DAO de creer les DTO à partir des données fournies par les beans

3) les DTO: qui servent à communiquer de façon interne en transportant les infos

4) les DAO: classes métiers qui accèdent à la base et retourne les infos sous forme de DTO.

Est-ce que je me trompe?

Autre question conernant les DAO: si j'ai bien compris, tu peux demander à un DAO de créer un DTO à partir d'un DTO partiel? je m'explique. Tu a un DTO user DTO contenant login, passwd, nom, ...
Je peux très bien remplir un DTO (depuis laction struts) avec seulement son login et password et demander au DAO de me retourner un DTO complet (contenant toutes les infos user) ou le cas échéant un DTO vide si l'utilisateur na pas été trouvé


jespere ne pas avoir tout compris de travers XD

[azerr]

Bonjour johan_b,
je me permets de m'initier dans votre conversation,
car je pense qu'il est aussi important d'avoir une couche Service
qui est entre les actions et les DAO.

J'ai fait un schema pour mon projet gestcv :
http://gestcv.sourceforge.net/fr/architecture.html

La couche service gere le metier de ton application (ex : un utilisateur doit avoir un login unique lors de sa creation). Les actions font appel a la couche service.

Si tu n'as pas cette couche les regles metiers tu devra les mettre soit :

* dans ton action. Probleme : d'autres application (ou d'autres actions) qui voudront avoir la meme regle de gestion devront dupliquer cette regle.

*dans ta DAO. Probleme : imagines que tu developpe une DAO qui cree un utilisateur et que tu mettes ta regles metiers dans ta DAO (login unique). Au cours du developpement, tu as besoin de creer pour un cas particulier un utilisateur qui aurrait le meme login. Tu ne peux plus reutiliser ta DAO. Si tu gere ton metier dans la couche Service. Tu aurras deux services differents qui appeleront la meme DAO.

La couche service a pour but aussi d'assembler les donnees retournes par les DAO pour construire une DTO (complexe ou non) (Attention de ne pas executer 40 milles requetes pour construire une DTO).

Dans mon schema, je parle aussi de Bean Persistent, car j'utilise Hibernate et Spring, mais bon je ne vais pas t'embrouiller plus.

J'espere que ca pourra t'aider. Si tu as le temps tu peux lire gestcv, car j'ai tente d'expliquer au mieux mon choix d'architecture.

Angelo

[djo.mos]

Bonjour.
Rassures toi : t'as pas tout compris à travers, mais ill y'a juste ton 2ième point qui divague un peu ...

2)Les struts Action qui prennent ce quil ya dans les bean et créent les DTO
A partir de ça on renvoie vers une vue qui utilise ces DTO (si seulement besoin d'afficher les infos ransmises par formulaire) ou demandent aux DAO de creer les DTO à partir des données fournies par les beans

Ca jamais ! les vues n'ont jamais jamais jamais accès aux DAOs ! C'est l'esprit même du MVC !

Donc, pour résumer, tu as 5 types de classes (en gros) :
1-Les DTOs : support de données
2-Les DAOs : gestion des DTOs en général avec la BD.
3-Les autres classes de la couche métier

4-Les ActionForm de Struts, une sorte de remake des DTOs, mais en moins de détail : par exemple, UserForm (login, pwd) tandis que UserDTO (login, pwd, nom, age, etc...). Les ActionForm sont en principe une représentation des formulaires des pages JSP.(Mais à mon avis c'est l'un des gros défauts de Struts, car on aurait pu utiliser directement les DTOs comme dans JSF)
5- Les Actions de Struts qui en gros effectuent 4 opérations dans la méthode execute :

1. Récupérer l'ActionForm associé à l'action et le convertir en DTO
2. Faire appel à la couche métier (aux DAOs et autres)
3. Stocker les résultats (des DTOs en général) dans le/les scopes de ton choix pour qu'ils soient disponibles aux vues.
4. Forwarder selon les résultats retournés par le Model.

Donc, les vues comme je l'ai dit n'ont jamais accès aux DAOs ! il récupèrent juste des DTOs que les actions stockent dans la session ou le request.

En ce qui concerne ta question sur les classes partiellement replies, etc. ça peut se faire, mais de préférence si tu utilises Hibernate comme couche de persistence (les Criterion et les Example font tout le sale boulot), mais avec JDBC seulement, ce serait vraiment un casse gueule ! Une telle opération se révèle surtout utile pour des recherches.

Pour l'exemple de connexion, tu peux aussi procéder comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
public class UserDao implements GenericDao<User, Long> {
  //implémentes les méthodes du généric Dao
 
  //Tu peux ajouter cette méthode
  public User validate(String aLogin, String aPwd){
  ..."SELECT * FROM user WHERE login=aLogin AND pwd=aPwd"...
  }
}

et dans la méthode execute() de LoginAction

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11

User u = (new UserDao()).validate(form.getLogin()
, form.getPwd()
);
if(u==null)
  return mapping.findForward("failure");
else {
  request.getSession.setAttribute("connectedUser", u);
  return mapping.findForward("success");
}

On évite comme ça le passage par la méthode findByExample.
Veuilles STP noter le fait que j'ai mis le DTO du User dans la session (3ième étape de Action.execute), comme ça, dans tes vues (pages JSP) tu peux affficher le nom de l'utilisateur connecté comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
<bean:write name="connectedUser" property="name" />

Un dernière chose : c'est du MVC mais fortement imprégné de ma vision des choses, donc ce ne sont pas les paroles du dieu, tu peux en tirer ce qui te plait et y ajouter de ton crue !

[azerr]

Bonjour Modjo,
je partage tout ce que tu viens de dire.

(Mais à mon avis c'est l'un des gros défauts de Struts, car on aurait pu utiliser directement les DTOs comme dans JSF)

Oui je suis d'accord pour la version Struts 1.x. La version Struts 2.x qui est base sur Webwork a supprime le concept d'ActionForm. Maintenant on peut utiliser sa DTO (d'apres ce que j'ai pu lire) dans son Action.

Un sujet qu'on oublie souvent et qui super chaud a gerer correctement est la gestion des connections (ouverture/fermeture connection, debut/fin transaction).

Je n'aime pas appeler directement la DAO dans l'action car cela signifie que

* soit l'Action Struts doit gerer les connections. Le probleme avec cette solution et que l'on cree un fort couplage a la base de donnee dans l'Action. Si on veut changer de type d'acces (ex : WebService) on ne peut pas.

* soit la DAO gere ces connections (ouverture/fermeture), ce qui signifie que l'on ne peut pas enchainer plusieurs DAO en utilisant la meme connection (ce qui est genant pour la gestion des transactions).

La couche service permet :

* gerer le metier de l'entreprise.
* gerer les ouverture/fermeture de connections. Autrement dit a l'appel d'un e method d'un service on ouvre une connection, a la fin de la methode on ferme la connection.

Le jour ou l'on souhaite changer de type d'acces aux donnees, seule la couche service est impactee.

L'enchainement des DAO (pour gerer une transaction) peut ensuite s'effectuer dans un service. Mais souvent on creer un service (ex: creerUtilisateur) , puis un autre (creerRole) et on souhaite enchainer l'appel de ces deux services a la suite. Mais ceci n'est pas possible car chaque method ouvre et ferme les connections. Avec l'AOP de Spring, on peut gerer ce cas. Je ne vais pas m'etaler sur le sujet, mais avec l'AOP de Spring, la problematique des gestions de connections est un vrai bonheur.

J'ai tente de l'expliquer ici :
http://gestcv.sourceforge.net/fr/arc...re/spring.html


Angelo

[djo.mos]

Pardon azerr, j'avais pas vu ton post (tu l'avais envoyé pendant que je rédigais le mien).

pour la couche Services ! J'avoue que j'y avais jamais pensé ! Je fesais tout un tas de maneuvres (sales pour la plupart) pour y arriver.

pour le fait d'évoquer le sujet des ouverture/fermetude des transactions mais surtout des sessions Hibernate : C'est un sujet super explosif, et tout programmeur ayant jonglé avec Hibernate dans une application web décente doit surement avoir de très mauvaises souvenirs sur les objets détachés et les lazy fetch Exceptions !

Je ne suis pas sur que ce post soit le bon endroit pour en discuter (on ne veut tout de même pas embrouiller johan_b ).

Je te propose alors de créer un nouveau post sur le sujet Hibernate dans une application web) à moins bien sur que ce ne soit déja fait !

[azerr]

Modjo, y a pas de souci.
Oui je suis d'accord avec toi, on va pas embrouiller johan_b avec Hibernate.
Si tu veux ouvrir un sujet sur Hibernate dans une appli WEB, y a pas de souci.
Si tu as le temps, tu peux lire la section Hibernate/Spring http://gestcv.sourceforge.net/fr/arc...re/spring.html pour te donner une idee de comment je fais.

Si tu ouvres un sujet, envoie moi un message sur ma boite de developpez.
Ca n'a rien avoir avec le sujet, mais je t'en parles a tout hasard :
je developpe un plugin Eclipse Akrogen http://akrogen.sourceforge.net/fr/ de generation de code qui permet d'ecrire ses Wizard pages Eclipse en XUL/XML et Javascript. Ceci permet de creer son propre catalogue de template (Freemarker, Velocity XSL,...) pour gerer ses composants. la generation de code se fait a travers des Wizrad pages Eclipse que tu decrit sen XML/XUL & Javascript.

Le plugin commence a etre operationnel, et je suis en train d'ecrire un exemple de catalogue (simple) pour generer lesAction, ActionForm,... de Struts 1.x.
J'ai l'impression que tu as pas mal d'experience au niveau architecture et si tu es interesse pour m'aider a ecrire d'autre catalogue (ex : l'architecture que tu utilises dans ton Entreprise), n'hesites pas a me contacter.

Angelo

[djo.mos]

D'accord pour le post, je vais avant vérifier cette soirée s'il n'y a pas une discussion similaire.

Pour le second point (Akrogen), ça peut être très interssant, mais actuellement je suis enlisé jusqu'au cou dans le dévéloppement d'une plateforme en JSF, et j'aurais donc pas le temps pour m'investir dans un autre projet ( à moins que Akrogen dure jusqu'à l'été, mon projet s'achève vers 25 Juin).

Je te contacterais sans faute tard cette soirée.

Bonne journée, il faut que je files maintenant.

[azerr]

Ok pas de souci,
j'attends de tes nouvelles pour le sujet concernat Hibernate.
Akrogen est un projet Open source donc des que tu as le temps et surtout si ca te motive, je serai ravie de concevoir ensemble un catalogue de template JSF (que je ne connais pas) par exemple.

Angelo

[johan_b]

ouais ouais commencez pas à trop m'embrouiller là je ne suis q'un petit débutant dans ce monde de brutes XD

Sinon concernant les réponses:
- déjà merci (ça c'est fait )

jamais accès aux DAOs ! C'est l'esprit même du MVC !

- j'ai du mal m'exprimer, car j'avais bien compris ça. Mes vues n'ont accès qu'aux DTO enregistrés en session ou en request (méthode setAttribute).

C'est juste au niveau de la couche métier que ça me pose des problemes.
Déjà je ne vais pas prendre en compte la couche service, tout simplement paske c un petit projet, mon permier surtout, et ça va m'embrouiller encore plus :p (promis je tiens ça en compte pour la suite )
Donc DAO pour tout ce qui est stockage et chargement de données, création d'utilisateurs... par accès à la base.

Concernant les DTO partiels, c'est juste histoire de pas se compliquer la tache et passer tout ce qui est necessaie dans un seul objet.
En ce qui concerne les DTO retournés par les DAO, je vais pas mamuser a créer plusieurs DTO par utilisateur (un contenant juste le login, d'autre contenant plus d'info, selon les demandes). Un DTO général est utilisé et les champs necessaires sont remplis, les autres nétant pas utilisés par les vues.

De plus, ça évite de passer 50 arguments à une fonction.

Si par exemple je veux faire en sorte d'envoyer un message d'un utilisateur à un autre:
J'ai les champs titre, date, contenu, et dautres qui servent à avoir plus d'info (ex: date d'envoi)
je crée un DTO user_expediteur, user_destination, et un message contenant seulement le titre et le contenu (le dto contient d'autres champs mais pa utilisés pour cet usage).
J'envoi le tout à un DAO message du genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
public class MsgDao implements GenericDao<User, Long> {
 
  public bool Envoyer(userDTO exp, userDTO dest, MessageDTO msg){
  //connection à la base, remplissage des tables necessaires, en ajoutant un champ date généré dans cette classe et dautres infos...
  }
}

et d'un autre coté je veux récupérer un message reçu:
j'utilise toujours le même DTO mais cette fois ci en allant chercher dans la base (toujours depuis le DAO), en remplissant le DTO avec tous les champs cette fois-ci (date y compris par exemple): d'ou le fait d'utiliser un seul DTO pour plusieurd actions possibles.
De même, le DTO user indiquant les peronnes ocncernée par le message seront les DTO utilisées pour les infos utilisateur (contenant nom, prenom...) mais seuls sont fournies les infos de login, le autres nétant pas necessaire

Au final ça mévitera d'utiliser plusieurs DTO et d'avoir deux fonction comme celles-ci par exemple

envoyermail(login_dest, login_exp, titre, contenu ...)
recevoir message(longin)

Bon sur cet exemple je suis pas credible mai imaginez qu'il me faille 50 parametres a passer dans le message


Au final j'imagine que c'est peut etre pas dans l'esprit MVC struts mais ça signifierai une création de DTO supplémentaires pas forcément utiles.

heu... je me suis perdu dans mon fil et j'ai du oublier la moitié des choses que je voulais dire, mais le fofo ets là pour ça :p

ps : merci encore ^^