Discussion :

[tatemilio2]

Bonjour, je souhaite avoir votre avis.
Je développe une application et je travaille actuellement sur l'accès aux données, après pas mal de lecture à droite à gauche voici le type d'architecture que je viens de mettre en place pour l'accès aux données.
Prenons une table de ma base de données (Utilisateur).

J'ai donc un POJO Utilisateur.
Je défini une interface pour mon DAO --> UtilisateurDAO (CRUD)
Implémentation grâce spring et son intégration d'hibernate --> UtilisateurDAOHibernate.
Et enfin j'ai défini des services qui seront appelés par l'IHM
Interface --> UtilisateurManager (CRUD)
et son implémentation --> UtilisateurManagerImpl qui appel mon UtilisateurDAO

Que pensez-vous de cela ? es pas un peu lourd de mettre deux niveaux service et DAO alors que les classes font la même chose (pour l'instant CRUD)?

[yaltar]

Bonjour,
je me permet de donner mon humble avis sur la question.

Effectivement cela peut paraître lourd, mais si c'était moi, je rajouterais encore quelque niveau de sépartion, par le biais de Business Delegate, entre la présentation et le "métier".


L'évotubilité (je sais pas si le mot existe), ce paye au pris de la "lourdeur" de toute les couches que l'ont met, et qui peuvent sembler ne servir à rien.
Mais le jour ou ... on se dit "Yeahhhh quelle bonne idée d'avoir 'alourdis' à l'époque, je n'ai qu'un endroit à changer pour évoluer".

Donc pour ma part, la présentation ne devrait jamais faire appel à du CRUD ... il devrait y avoir un controlleur metier entre les deux.

Entre la présenation et le controlleur métier, devrait y avoir une business delegate, et un service locator ....., idem entre le métier et l'accés au données.


Mais bon je pense que je m'éloigne un peu du sujet, et il me semble que le peux que je connaissance de spring, simplifie la notion de service locator, par le biais, de l'injection, et de IOC.

En espèrant avoir fait avancer les chose.

[tatemilio2]

Bonjour,
Merci de ta réponse, par contre au niveau séparation des couche présentation et métier cela ne te semble pas suffisant d'avoir mon interface UtilisateurManager ?


Pour résumer j'ai :

IHM --> Manager --> DAO --> Entity --> BDD.

Cela me parais suffisant non ? je ne vois pas l'intérêt de rajouter encore une couche entre mon IHM et mes managers.
De plus pour l'évolution de mon application, je travaille avec les interfaces et non pas les implémentation.
L'intérête de Spring est que je peux définir quelle est l'implémentation utilisée et par inversion de controle, je peux initialiser correctement mes objets.

[yaltar]

Effectivement, on peut assimilier ton Manager, à ce que j'appelais Business Delagte (enfin ce n'est pas de moi, c'est un design pattern).

Et il vrai qu'avec Spring, comme je l'ai dis à la fin de mon message, l'évolution sera plus simple.
Ceci étant t'a présentation à quand même une connaissance "forte" du crud, ce que personnelement je n'aime guere

Pour ma part, j'aurais au minimum dans ton cas :
- Présentation - Métier - Données
IHM --> Manager --> Controleur --> Entity --> DAO --> BDD.

En se basant sur spring et le fait de pouvoir injecter les bonnes implémentations.

Mais pour ma part, ne voulant pas être dépendant, même si j'utilise spring, je rajouterais toutes les couches, même si spring fait une "simple" injection dans certaines des couches, ca me permettrais, le jour ou je décide de me débarasser de spring, de le faire à "moindre" coup

[fr1man]

J'ai travaillé sur un projet qui était basé sur la même architecture que toi.
Je trouve cela bien suffisant, mais après ça dépend des besoins.
Ce type d'architecture est recommandé dans le bouquin "spring par la pratique".
Je ne comprends pas bien à quoi servirait les autres couches proposées, ne connaissant pas précisemment les patterns en question.

[*alexandre*]

IHM -> Business Service + Business Entity-> DAO -> DB Entity -> DB

cela permetd ignorer que tes objets que tu créer dans tes services sont des objets DB (visibilité d un objet DB uniquement en private)