Architecture d'un projet web

Version imprimable

31/12/2010, 15h24
lotfi-g

Architecture d'un projet web

Bonjour,

J'aimerai prendre vos conseils sur l'architecture d'un projet web avec Spring. j'ai lu pas mal d'articles sur comment organisé les classes, les interfaces et les packages. Mon projet est simple mais j'ai voulu juste l'organiser en séparant chaque couche à part.

le modèle UML du projet est la suivantes. j'ai 4 tables (contact,adresse,phonenumber,groupContact,ebtreprise) qui sont reliés par des relations de type (many-to-many, one-to_many,heritage,etc).

les actions que je peut le faire (ajout,suppresion,modification,recherche). la base de données est Mysql.

J'ai réussi a faire marché tout ca mais lorsque je vois mon projet c'est le grand bazar j'ai toutes mes classes dans un seul package. je n'ai pas utilisé aucune interface.

Je sait bien qu'il faut séparer entre les vues utilisateur, métier, accès aux données. Mais j'arrive pas à les distinguer.

merci.
31/12/2010, 16h04
r.othman

Je te conseil l'organisation suivante, mais il y en a d'autres aussi, ce n'est qu'un exemple, à toi de voir ce qui te convient le mieux ;)

Pour les objets métier : ton.package.entities ou bien model sinon businessmodel

Pour les fonctions CRUD : ton.package.services pour les interfaces, et ton.package.services.impl pour les classes concrètes.

Quant à la vue, tu as des pages web et des controllers qui les gèrent : ton.package.web.controllers, les pages étant dans un sous-dossier views de ton WEB-INF.

Les fichiers de config sont presque tous dans le dossier WEB-INF...

voilà, c'est comme ça que je fais, et je trouve que ça reste quand même bordélique malgré tout :aie:
31/12/2010, 16h20
lotfi-g

re

Merci pour ta réponse.

Citation:

Envoyé par r.othman

Je te conseil l'organisation suivante, mais il y en a d'autres aussi, ce n'est qu'un exemple, à toi de voir ce qui te convient le mieux ;)

Pour les objets métier : ton.package.entities ou bien model sinon businessmodel

j'ai pas bien saisi c'est exactement les objets métier est ce que se sont les fonction d'ajout de suppression et modifications si c'est le cas je fais quoi dans la couche accès au données car j'ai une classe DAO qui contient les méthode d'ajout,suppression et modification.

Pour les fonctions CRUD : ton.package.services pour les interfaces, et ton.package.services.impl pour les classes concrètes.

c'est quoi les fonction CRUD ? en faite je vois pas l'utilité exacte de l'utilisation des interfaces.

Quant à la vue, tu as des pages web et des controllers qui les gèrent : ton.package.web.controllers, les pages étant dans un sous-dossier views de ton WEB-INF.

oui j'ai des pages jsp pour les formulaires et les affichages

Les fichiers de config sont presque tous dans le dossier WEB-INF...

voilà, c'est comme ça que je fais, et je trouve que ça reste quand même bordélique malgré tout :aie:

finalement, je te décrit un peu petit le fonctionnement d'un exemple . Après l'identification de l'utilisateur il choisi une des fonctions à réaliser il rempli un formulaire un pages jsp qui va envoyer les données à une servlet cette dernière récupère les données et appel une des méthodes de la classe DAO qui se charge d'ajouter ou de supprimer ou de modifier le contact dans la base de données.
31/12/2010, 20h06
r.othman
Le fonctions CRUD sont tout simplement : CReate Update Delete ;)

Tes DAO s'occupent de l'enregistrement en base de données, par exemple MySQL dans ton cas.

La couche Services elle va utiliser tes DAO pour l'enregistrement et faire d'autres tâches, on parle de logique métier...faire des calculs, vérifier qu'un montant est supérieur à un seuil...etc.

L'utilité des interfaces est que si dans ta couche Service tu souhaite changer tes DAO, pour disons passer sur une base SQLite, tu n'auras pas a changer le code sources des Services, juste l'injection de nouveaux DAO SQLite,
Code:

1 2 3 4 class UserServiceImpl implements UserService { UserDAO userDAO; }
et tes DAO :
Code:

1 2 3 4 class MySQLUserDAO implements UserDAO {....} class SQLiteUserDAO implements UserDAO{....}
avec ton fichier de config Spring, si tu veux passer d'une base MySQL à une base SQLite, tu le fais simplement en changeant le bean "UserDAO" qui sera injecté dans ton service, et ton service tu ne le touche plus :)
02/01/2011, 19h45
lotfi-g

Je vois que la discussion n'est pas intéressante pour la comité développez ou peut être qu'ils font encore la fête :-) .
03/01/2011, 11h39
OButterlin

Citation:

Envoyé par lotfi-g

Je vois que la discussion n'est pas intéressante pour la comité développez ou peut être qu'ils font encore la fête :-) .

Lendemains obscures en tout cas... :aie:

Si tu veux découper en couches (fortement recommandé), tu peux t'appuyer sur l'architecture MVC, elle s'y prête bien.
Tu pourrais avoir ces packages :

ton.application.model (pour tout ce qui concerne le modèle métier)
ton.application.vue (pour tout ce qui concerne les données utilisées par les pages jsp)
ton.application.controleur (pour les contrôleurs de formulaires)

Tu peux accessoirement subdiviser model en model.entity, model.dao (+ model.crud si tu veux séparer mais pour moi, c'est un dao).

Après, les pages jsp peuvent être placées dans un répertoire "vue" sous WebContent (ou Web-Inf).
Il pourrait être judicieux également de subdiviser les différents éléments par thème (contact, entreprise, adresse, ...)

Bref, il y a beaucoup de façon de voir la chose, la seule chose certaine, c'est que tout mettre au même niveau ne va pas aider à la maintenance.

Pour ce qui est des interfaces, si tu as une notion de "contrat" qui se rattache à plusieurs classes, alors oui, il faudrait les utiliser pour une meilleure abstraction.
09/01/2011, 18h16
lotfi-g

Bonjour

juste une questions vous voulez dire quoi par notion de contrat.

merci
10/01/2011, 09h04
OButterlin

Le principe d'une interface est de définir un "contrat".
Une classe implémentant une interface s'engage à répondre intégralement au contrat.
Plusieurs classes peuvent implémenter une même interface.

Un exemple : on va parler d'une interface "déplaçable".
Elle aura comme méthodes :
- tourner à droite
- tourner à gauche
- avancer
- reculer

Une voiture implémentera "déplaçable", un bateau également, un avion aussi etc...
Pourtant, le code permettant de déplacer ces "mobiles" est très spécifique.
Charge à chacun de faire ce qu'il y a à faire.

Maintenant, si on se place d'un point de vue contrôleur de "mobiles", on va traiter notre liste d'objets au travers de l'interface "déplaçable" (alors que physiquement, on a une classe Voiture, Bateau, Avion...)
De ce fait, on se fiche royalement de la classe d'instance, on ne la voit que sous sa forme contractuelle et on peut les déplacer en utilisant directement les méthodes adéquates.
Si demain un autre type d'objet doit être ajouté, rien ne change du côté du contrôleur.
20/01/2011, 18h17
mesken

Citation:

envoyé par OButterlin
ton.application.model (pour tout ce qui concerne le modèle métier)
ton.application.vue (pour tout ce qui concerne les données utilisées par les pages jsp)
ton.application.controleur (pour les contrôleurs de formulaires)

Citation:

Et envoyé par r.othman
Pour les objets métier : ton.package.entities ou bien model sinon businessmodel

Pour les fonctions CRUD : ton.package.services pour les interfaces, et ton.package.services.impl pour les classes concrètes.

Quant à la vue, tu as des pages web et des controllers qui les gèrent : ton.package.web.controllers, les pages étant dans un sous-dossier views de ton WEB-INF.

1) Que faire s'il vous plait si j'ai une application qui intègre par exemple la gestion du stock, la gestion du personnel et la gestion des finances ? Est ce que je vais mettre le modèle métier de ces trois schéma/modules dans le même package ?

2) Et si on veut intégrer Hibernate, comment sera gérer le.package.entities ?
20/01/2011, 19h20
ray_fab

Le principe dans une application d'avoir une bonne sépararation en couche une fois que la séparation en couche est faite, le choix des packages ne se pose plus. Tout ce qui se fait dans une architecture en couche ne doit concerner que les interfaces, car seules les interfaces seront utilisées par Spring à part la couche de persistence ou les objets sont des POJO, et peut être la classe du contrôleur. Une architecture classique est d'avoir une couche de persistance, une couche dao,une couche service, et une couche web. Seule la couche service gérée par Spring tisse le lien entre les différentes couches. Si on choisi d'appeler le packqge par défaut fr.appli, pourquoi pas avoir fr.appli.persistence, pour la couche de persistance, fr.appli.dao pour l'interface dao et fr.appli.dao.impl pour l'implémentation ainsi de suite pas la peine de se prendre la tête les gens...