Discussion :

[lotfi-g]

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.

[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

[lotfi-g]

Merci pour ta réponse.

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

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.

[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 :

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

1
2
3
4
 
class UserServiceImpl implements UserService {
    UserDAO userDAO;
}

et tes DAO :

Code :

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

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

[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 :-) .

[OButterlin]

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...

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.