Houla, c'est pas très J2EE-compliant, tout ça.
Alors il y a du boulot pour éviter de mélanger toutes les couches comme tu le fais.
Ce que je vais te dire, c'est bcp bcp de boulot supplémentaire, mais c'est l'architecture "canonique" d'une appli J2EE qu'il faut apprendre à respecter.
Pour la couche web, il vaut mieux éviter de coder directement des JSP mais apprendre à utiliser un framework de présentation existant qui aidera à séparer les couches Model/View/Controller. Il y en a bcp, tu peux essayer Stripes (google Stripes framework), par exemple.
Ensuite, pour l'accès à la base de données, le codage en JDBC, c'est fini (ou ça devrait l'être). Aujourd'hui on utilise une couche d'abstraction qui permet un "mapping" entre les tables et les objets métier. Bien souvent, si le modèle de données n'est pas complètement stupide, on peut avoir une correspondance table <--> objet métier. Les ORM comme Ibatis, Hibernate ou JDO génèrent automatiquement des classes avec les requêtes pour la création, l'accès, l'update et le delete des éléments dans toutes les tables mappées. Les classes générées sont des DAO "Data Access Objects". Comme c'est du code généré, on n'y touche pas, on se contente d'utiliser ces classes pour récupérer/updater les données en base.
Ensuite il faut réfléchir à tes objets "métiers" nommés Value Objects (VO), qui sont typiquement des JavaBeans, càd des objets avec des attributs privés et des getters/setters (qui peuvent être générés automatiquement par un IDE comme eclipse) et une méthode toString() pour afficher leur contenu à tout moment. Comme les DAO, les VO sont bien souvent à l'image des tables (par contre, clés et autres contraintes d'intégrités ne sont pas mappées).
Par exemple si tu fais un site commerçant avec un caddie et des références produits que tu peux ajouter/enlever de ton caddie, tu peux typiquement créer des value objets ClientVO, CaddieVO et ReferenceVO. Les value objects sont des objets retournés ou passés en paramètre des objets "métier" (Business objects, BO) qui font le coeur de l'application. Comme leur nom l'indique, les VO ne sont que des objets légers qui contiennent des valeurs et ne font rien d'autre.
Ex:
Code :
- public class CaddieVO {
- List<ReferenceVO> refListe;
- List<ReferenceVO> getRefListe() { return refListe; }
- void setRefListe(List<ReferenceVO> refListe) { this.refListe = refListe; }
- String toString(){
- StringBuffer str = new StringBuffer();
- for(ReferenceVO ref: refListe) if(ref != null) str.append("{" + ref.toString() + "} " );
- return str;
- }
- }
|
C'est dans les BO que l'on va écrire les méthodes qui définissent l'application.
Par ex:
Code :
- public class GestionCaddieBO{
- public void ajoute(CaddieVO caddie, ReferenceVO ref){...}
- public void supprime(CaddieVO caddie, ReferenceVO ref){...}
- }
|
Tu peux aussi avec une classe Caddie que tu utiliseras éventuellement dans la classe GestionCaddieBO
Code :
- public class CaddieBO{
- ClientVO getClient(){ CaddieDAOFactory.getClient(); }
- public void ajoute(ReferenceVO ref){ ReferenceDAOFactory.getInstance(getClient()).add(ref); }
- public void supprime(ReferenceVO ref){ ReferenceDAOFactory.getInstance(getClient()).delete(ref);}
- public void vide(){ // vide le caddie}
- }
|
La classe GestionCaddieBO se chargera alors de gérer les transactions ou autres.
Les VO sont aussi transmis à la couche présentation. Leur usage permet de fluidifier le transport de données à travers toutes les couches de l'application.
Ainsi, si tu utilises Stripes, tu peux définir CaddieActionBean extends CaddieBO implements ActionBean, et ton VO est immédiatement utilisables par la couche de présentation. On peut aussi ajouter des propriétés intéressantes aux VO, comme implements serializable, ou les utiliser pour les XML-sérialiser avec une librairie comme xstream, par ex.
Comme tu le vois, par rapport à ce que tu fais, c'est un peu une usine à gaz, mais sur une appli non triviale, un tel découpage est bénéfique, pour ne pas dire nécessaire. Ne serait-ce que parce que toute la partie métier est maintenant facilement débogable au debogueur (c'est du Java pur et non des JSP), et qu'avec un framework comme Stripes, il n'y a plus de code dans les JSP. Je ne sais pas si j'ai été clair, mais avec les tutoriels de Stripes, tu apprendras à reconnaitre les différents types d'objets.
(edit: et à part ça, dans ton code JDBC, il faut fermer le statement et la connexion dans une clause finally, mais de toute façon, ce n'est pas la bonne façon de faire des JSP)
Message édité par el muchacho le 01-06-2008 à 22:01:04
---------------
Les aéroports où il fait bon attendre, voila un topic qu'il est bien
