Problème de conception autour des modèles
Bonjour à tous,
Je viens vers vous autour d'une question de conception sur ces fameux model wicket. J'aimerai en fait savoir quelle politique adopter. En effet je dois construire des panels qui contiennent des informations métiers provenant d'objets métier divers.
Un exemple :
PlanningPanel
Rendez-vous de type A : le vendredi 13 janvier de 18h00 à 20h annulé. + (ici un lien vers un popin qui affiche une liste de rdv de type A)
Rendez-vous de type B : le samedi 11 décembre de 18h00 à 20h terminé. + (ici un lien vers un popin qui affiche une liste de rdv de type B)
Date de livraison prévu : 15 janvier 2011
Date de déménagement : 25 janvier 2011
--
Aujourd'hui ce qui est fait est très vilain en mon sens car ça donne un truc du genre
PrincipalPanel.java
Code:
1
2
3
4
5
6
7
8
9
10
11
12
|
public class PrincipalPanel extends Panel{
...
public PrincipalPanel () {
...
PlanningBean planningBean = planningService.creerBean(reponseWS);
add(new PlanningPanel("planning", planningBean));
...
} |
PlanningPanel.java
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
public class PlanningPanel extends Panel {
...
public PlanningPanel (String id, PlanningBean bean) {
...
add(new Label('typeRdvA', bean.getRDVTypeA().getType()));
add(new Label('libelleDateRDVA', bean.getRDVTypeA().getLibelleDate()));
...
add(new Label('labelDatePrevu', bean.getLibelleDate());
add(new Label('datePrevu', DateUtils.parseDate(bean.getDatePrevu()).setVisible(bean.getDatePrevu()!=null);
}
} |
Voici le genre de chose que l'on peut voir dans l'application sur laquelle je travaille en ce moment, sachant que je vous épargne des tonnes de if pour les règles de gestion. Vous remarquerez qu'on n'utilise à aucun moment les model wicket ce qui est très mal et je pense c'est pourquoi aujourd'hui on a des problèmes de mémoire.
En fait le principe de ça c'est qu'on crée un "bean" de ce que le composant va afficher. Ce bean est créer à partir d'une couche service qui parcours le résultat d'un web service qui contient toutes les informations dont on a besoin (et plus ) pour afficher la page. Le gros problème de tout ça c'est qu'on des règles de gestions qui sont complétement mélangées on construit des phrases dans la couche de service alors qu'elles devraient être construite côté présentation, bref c'est un gros sac de spaghetti, et quand on doit faire des modifications c'est la pagaille.
Je suis chargé de refactorer et de mettre un peu d'ordre dans tout ça et au passage régler les problèmes mémoires. :zoubi:
Donc voici ma vision des choses :
Le web service remonte toutes les informations (ça j'ai pas le choix c'est comme ça) j'ai une première couche qui se charge de traduire l'objet réponse du Web service en objet métier c'est à dire des objets de type RendezVous , Commande, Client, DossierClient...
Puis une couche service qui parcoure ces objets métier pour récupérer les infos dont j'ai besoins puis la vue qui se charge d’afficher tout ça.
Donc voici plus concrètement à quoi ça risque de ressembler
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
|
public class DossierClient implements Serializable{
private String refId;
private List<RendezVous> rendezVousTypeA;
private List<RendezVous> rendezVousTypeB;
private Commande commandePrincipale;
private List<Commande> lesCommandes;
get();
set();
}
}
public class RendezVous implements Serializable{
private TYPE_RDV type;
private Date date;
private STATUT_RDV statut;
get; set;
}
public class Commande implements Serializable{
private String refId;
private Date datePrevu;
private Date dateDemenagement;
} |
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
|
public class PlanningPanel extends Panel{
public PlanningPanel (final DossierClient dossierClient){
IModel<RendezVous> rdvTypeAModel = new AbstractReadOnlyModel (){
public RendezVous getObject(){
// ou passer par une couche de service de service si les regles sont plus compliqués
return dossierClient.getRendezVousTypeA().get(0);
}
};
add("type", new PropertyModel(rdvTypeAModel , "type"));
add(DateLabel.forDateStyle("date",new PropertyModel(rdvTypeAModel , "date"),DateUtile.getPatterns);
...
IModel<Commande> commandeModel = new AbstractReadOnlyModel(){
public RendezVous getObject(){
// ou passer par une couche de service de service si les regles sont plus compliqués
return dossierClient.getCommande();
}
};
// le libellé du début serait dans un wicketMessage par exemple
add(DateLabel.forDateStyle("datePrevue",new PropertyModel(commandeModel , "datePrevue"),DateUtile.getPatterns);
add(DateLabel.forDateStyle("dateDemenagement",new PropertyModel(commandeModel , "datePrevue"),DateUtile.getPatterns);
} |
Si vous avez eu le courage de lire tout ça, ma question est : suis-je dans la bonne direction ou dois-je continuer à avoir une approche "composant" mais en utilisant les model ?
Sachant que je n'ai trouvé aucun exemple où dans un composant wicket on avez deux model de nature différentes (ici je récupéré des rendez-vous et une commande).
Puis la particularité de mon appli c'est que les données remontent toute d'un coup par web service, j'ai pas de couche de persistance.
Merci beaucoup d'avance pour vos remarques
