Comment séparer les différentes couches d'accès au données au niveau du code?

**abir84** · 26/06/2007, 11h18

Bonjour à tous

Voila je ne sais pas si je suis dans la bonne rubrique. Je voudrai savoir comment séparer le code (interface utilisateur) des différentes autres couches (accès aux données...).

En fait, j'ai développé une application, j'ai fait une classe qui s'occupe de l'accès aux données et les autres pour l'interface utilisateurs qui appellent cette classe. MAis en la montrant aux experts on m'a dit qu'il faut une séparation réelle... et on m'a aussi parlé d'injection sql.

Franchement j'ai pas bien compris ce qu'il faut faire et comment mettre en pratique la séparation des couches (métier, accès aux données, ui...)

Merci d'avance

**CyberChouan** · 26/06/2007, 12h08

Je pense que ce que tes experts ont voulu dire, c'est que la séparation IHM/Accès aux données n'est pas suffisante.

En général, on ajoute une couche intermédiaire entre les deux. Ainsi, on se retrouve avec 3 types de classes:

- les classes de l'IHM
- les classes d'accès aux données
- les classes intermédiaires, appelées "contrôleurs", qui font le lien entre données et IHM

Si ton application effectues des traitements compliqués (partie "métier"), tu peux séparer celle-ci dans une couche supplémentaire

**abir84** · 27/06/2007, 11h18

Bonjour,

Si j'ai bien compris c'est que je dois séparer ces parties en des classes séparées. Par exemple une classe pour l'intrface qui fait appelle à une autre classe s'occupant de l'accès aux bases de données?? Mais c'est ce que j'ai fait!!

Mais je crois il y a des solutions plus professionnelles (genre bibliothèque de classes pour la partie accès aux données??)

En plus cette solution ne résoud pas le problème d'injection sql.

Excusez moi je suis débutante et j'ai encore beaucoup de progrès à faire

Merci

**BugFactory** · 27/06/2007, 11h35

Injection SQL : http://fr.wikipedia.org/wiki/Injection_SQL

Concernant la séparation des couches.
Votre classe d'interface appelle directement votre classe d'accès aux données, n'est-ce pas? C'est une pratique à éviter.
Le mieux est de définir une interface définissant toutes les méthodes d'accès aux données. (Interface au sens Java du terme, c'est à dire une pseudo classe vide déclarée par le mot clé "interface" plutôt que classe, je ne parle pas ici de l'IHM.) Ensuite, vous créez une implémentation séparée de cette interface. (En Java, une classe héritant de cette interface.)
Les classes appellantes ne connaissent pas la classe d'implémentation, elles ne connaissent que l'interface. Ainsi, il est possible de changer d'implémentation sans changer les classes clientes. Typiquement, un service tiers est chargé de retrouver l'implémentation quand une classe appellante demande une interface.

Comme l'a dit CyberChouan, vous pouvez également séparer la couche métier. Typiquement, la couche métier ne fait qu'appeller la couche donnée, mais contient toute la logique applicative quand il y en a.

Pour aller plus loin, vous pouvez vous renseigner sur "MVC". Le framework Spring peut vous être utile, mais c'est un gros morceau à avaler pour un débutant.

**abir84** · 03/07/2007, 11h46

Bonjour,

Voila j'ai trouvé sur developpez.com un bon document parlant du développement en couche. Les exemples sont en .NET et il est bien pour les débutants (comme moi) :
ftp://ftp-developpez.com/morpheus/ar...chitecture.pdf

Maintenant j'ai une question, une fois on a le sujet de l'application à développer par ou on doit commencer? (cahier de charge, choix de plateforme, ...)

**CyberChouan** · 03/07/2007, 13h39

Là ce qu'il te faut, c'est un cours de Management de projet informatique...

Dans l'ordre, on commence par rédiger le cahier des charges
Le choix de l'architecture dépend de celui-ci, et d'un certain nombre de points que le cahier des charges est supposé préciser:
- le projet doit-il durer dans le temps et être maintenu sur le long terme?
- comment est-il dimentionné? en terme de complexité, de charge, de nombre d'utilisateurs à l'utiliser simultanément...
- doit-il être tolérant à la panne? (système critique devant pouvoir fonctionner en mode dégradé...)
- etc...

En fonction de ces points (et de beaucoup d'autres), on choisit l'architecture la mieux adaptée. Par exemple, pour un petit projet, il n'est pas forcément nécessaire d'utiliser Spring + Struts + hibernate + Maven + etc...
Par contre, ces Frameworks deveindront nécessaires pour des projets de plus grande envergure

Maintenant, tu n'as à te poser ces questions que si tu fais partie de l'équipe de conception. Et le choix final revient toujours au chef de projet. Si tu n'es que membre de l'équipe projet, tu peux proposer des solutions et dire ce que tu envisages mais tu n'as qu'un avis consultatif.

Du moins, c'est comme ça que les choses devraient se passer...

**abir84** · 05/07/2007, 12h09

Merci pour les conseils, les choses sont plus claires mnt

Envoyé par CyberChouan

Maintenant, tu n'as à te poser ces questions que si tu fais partie de l'équipe de conception. Et le choix final revient toujours au chef de projet. Si tu n'es que membre de l'équipe projet, tu peux proposer des solutions et dire ce que tu envisages mais tu n'as qu'un avis consultatif.

Il faut dire que je suis tte l'équipe

(concepteur, developpeur...) , en effet j'ai developpé une appli qui a été très mal faite (sans conception et avec plein de beug...). Donc je veux tout refaire dans les règles de l'art ...

pour oublier la honte et les critiques du 1er essai

Mais j'ai une chose très floue dans ma tête : la relation entre les classes et la base de données. Est ce qu'il y a un SGBD permettant de stocker une base de données objet et non pas relationnelle. C'est plus facile a mon avis...

Merci

**CyberChouan** · 05/07/2007, 12h29

Le Framework Hibernate a été développé spécialement pour ça.

Il te permet de faire le mapping entre tes objets java et une base de données relationnelle de manière transparente. Il te "suffit" d'écrire le fichier de mapping et de spécifier les paramètres d'accès à la base de données.

Ensuite, tu invoques les méthodes de persistance => hibernate stocke ton objet dans la base de données, le met à jour, et régénère ton objet java à partir des données du SGBD.

De plus, hibernate a le bon goût de s'interfacer avec tous les SGBD usuels (Oracle, postgreSQL...)

**Mister Nono** · 05/07/2007, 12h33

Un peu pour résumer ce post car cela n'est pas toujours évident : concentre-toi sur le modèle MVC (Modèle-Vue-Contrôleur) et Hibernate (Persistance des données).

Bon travail car là il y a de quoi t'occuper.