Discussion :

[sepointes]

bonjour à tous

j'aurais besoin d'avis d'expert sur le découpage d'une application et notamment sur les servlets

je ne sais pas trop quand créer une nouvelle servlet : une par jsp, une par fonctionnalité, une seule pour toute l'application.
D'une manière générale je suis confronté à des doutes sur la meilleure façon de structurer mon code et d'organiser mes classes

J'ai également vu des appli JEE qui allait plus loin que le concept MVC et qui était organisé autour du concept de service/métier/dao (la servlet servant uniquement à récupérer les paramètres et appeler le service correspondant qui lui utilise les bons dao et créer les objets métiers retournés a la servlet )

que pensez vous de ce type d'organisation?

j'ai du mal en fait a décider comment organiser mon application

J'espere que certains d'entres vous pourront m'aider

[ruscov]

Je vais te donner la découpe d'une application J2EE classique. Après il y en aura toujours pour dire que tel ou tel est mieux, blablabla... Ce que je te donne ici c'est le découpage que tu rencontreras de manière classique un peu partout.

JSP <--> Servlet <---> Service <----> Dao <---> Base de données

Ta servlet est la couche qui va préparer la vue ou intercepter les requêtes de la vue. Il n'y a pas de règles en soit sur la fragmentation mais il est d'usage qu'une servlet puisse intercepter et renvoyer plusieurs requêtes qui tournent autour d'un module de ton application. Typiquement le CRUD (Create-Read-Update-Delete).

Ta couche service est l'endroit où tu vas écrire ton business. Elle doit être complètement indépendante de ta vue! Si jamais tu as des calculs à faire, c'est ici que ca se passe.

Ta couche Dao est la partie qui gère l'accès à la base de données. C'set ici que tu fais tes requêtes et tout ce qui touche à l'accès base de données. Pas de business ici!!

Voilà les bases d'une appli web Java

[sepointes]

Merci pour ta réponse
ta règle pour les servlets (une servlet pour un module) est surement le meilleur compromis

Par contre dans ton découpage il n' y a pas de couche métier? (les objets de l'application)
entre le service et le Dao?

[ruscov]

pardon, j'ai oublié, tu dois avoir un package model qui contient tous tes POJO(qui ne sont finalement qu'une représentation des tables de ta DB).

Ces entités seront transportées de couche en couche via les retour de tes méthodes. Exemple

Code :

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

1
2
3
4
5
6
7
8
 
class MyService
 
private MyPojoDao myPojoDao;
 
public MyPojo findById(Long id){
   return myPojoDao.findById(id);
}

Cette méthode sera appellée par ton servlet. Et au niveau du Dao, tu fais ta requêtes SQL et tu remplis ton POJO que tu renvoie au retour de méthode.

Ici j'ai pris volontairement un cas basique. Tu verras dans la pratique que ce genre de cas peut se traiter avec des génériques afin d'éviter de réécrire le même code pour chaque POJO.

[sepointes]

Merci beaucoup
c'est déjà plus clair
après il faut se lancer dans la pratique pour que ça devienne plus concret

[ruscov]

Tout dépend de la technologie que tu vas utiliser.

Moi je suis partisan du couplage Spring MVC (ou Struts 2) / Spring / Hibernate.

Si tu cherche dans Google des tutos avec ces frameworks, tu verras plein d'exemple complet qui implémente le découpage que je t'ai décris.