Discussion :

[misterdod]

Bonjour,

J'ai pu voir des sujets ressemblant à ce qui suit mais soit datant d'avant 2007 ou bien sans vraiment de réponses claires.

Dans le cadre de développement d'un projet spring / angular se pose la question de séparation des couches côté projet spring pour lequel il y a quelques débats dans notre équipe de dev (entre un architecte et différents développeurs plus ou moins expérimentés sur le fmk spring).

On voit bien une séparation de couches qui est :
Controller(API) / Service (métier) / DAO (persistance)
mais la séparation ne satisfait pas l'architecte dès que l'on évoque le fait que l'objet manipulé dans les services métiers est la classe construite dans la couche DAO et reflétant la DB. Ce qui en effet a pour conséquence de provoquer un couplage métier <> DAO. Donc si un jour on change la structure des tables (split d'une table en 2, déplacements de données de santés vers autre DB, ...) cela induit une modification des classes persistantes et donc potentiellement impact côté couche métier.

Pour la partie Controller on a opté pour une utilisation de DTO pour pouvoir maîtriser ce qui est transféré ou non avec la vue (exemple : afficher les données User sans le mot de passe...).

La proposition de l'architecte serait grossomodo, si je prend un simple cas Person, d'en avoir 3 classes :
PersonDTO : classe utilisée pour la manipulation côté Controller
PersonModel : classe utilisée pour la manipulation côté métier
PersonEntity : classe utilisée pour la persistance de données
(les noms ne sont pas forcéments exhaustif mais pour un soucis de compréhension).

De ce fait, chaque couche à sa propre modélisation d'une person et est donc indépendante, il y aura cependant nécessité de faire 2 phases de mapping :
DTO > Model puis Model > Entity (et inversement).


J'aurais donc voulu avoir votre opinion sur ce sujet pour "aider" à trancher.
Qu'est-ce qui fait qu'avec le fmk Spring ou a ce (fort) couplage entre métier et DAO? Alors que durant les développements passés on s'efforçait de bien séparer les couches.
Y a t-il une façon gérer par le fmk pour avoir un faible couplage ?
....

Je ne suis pas forcément claire dans les questions, mais notre but à l'heure actuelle est de savoir si l'on part sur une solution à moitié maison pour un inclure une couche métier totalement indépendante ou bien de partir sur une solution classique avec ce risque de couplage.

Merci d'avance pour vos réponses et votre aide.
Si je n'ai pas été suffisamment clair n'hésitez pas à le faire savoir et je pourrais apporter précisions ou reformulation.
Bonne soirée.

[PhilippeGibault]

La question est à mettre en parallèle avec le modèle en couche en réseau:
https://fr.wikipedia.org/wiki/Couche_r%C3%A9seau

De là, on en déduit le principe suivant: Je sais ce que tu fais, mais je ne veux pas savoir comment tu es codé.

C'est entre autre pour ça que l'on injecte des interface (et non des classes). Entre autre, ça permet d'injecter d'autres implémentations (Design Pattern Stratégie).

Les couches sont donc (en partant du haut):
Contrôleur
Service (avec objet métier DTO)
DAO (avec objet métier Entité).

En général, on enlève des informations de l'Entité au service.

Enfin, la couche du dessus n'a conscience que la couche du dessous. La couche contrôleur ne sait pas que la couche DAO existe.

Cordialement.

[OButterlin]

Je ne suis pas un spécialiste de Spring mais de JEE, ceci dit, les 2 se ressemblent donc, je me permets de soumettre mon point de vue.

Dans les applications web que nous construisons, le découpage ressemble un peu à ce que tu décris et la séparation est la suivante :

- la couche IHM qui reçoit des DTOs de la couche métier qui est un EJB façade (pattern façade). Cette façade est exclusivement liée au besoins de l'application IHM, les DTOs sont donc eux aussi liés à l'application IHM.

- la couche métier (l'EJB façade) couple les EJBs qui représentent les DAOs de base. C'est cette couche (la façade) qui transforme les DTOs en Entity et inversement via des méthodes du genre personne2DTOPersonne(Personne personne) et dtoPersonne2Personne(DTOPersonne dtoPersonne)

- les EJB DAO manipulent les objets Entity


Du coup, si les Entity étaient vouées à changer, seule la couche d'adaptation de la façade serait impactée, l'application IHM n'étant pas impactée.
Il va de soi que ça fonctionne dans certaines limites de modifications, tant qu'on ajoute des colonnes optionnelles ou dont la valeur est connue pour les anciens enregistrements... il n'y a pas de solution miracle

[Badshade23]

Personnellement j'ai appris ainsi :


De la droite à la gauche :
- Ta DAO communique avec la BDD et instancie tes entités. (JpaRepository ...)
- Ton Service connait ta DAO (via Autowired) et l'appel puis map ton métier en DTO.
- Ton IHM connait ton Service (via Autowired) et l'appel pour récupérer les données au format DTO ( à voir si tu veux rajouter un couche en transformant ton metierDTO en metierIHM).

Au final si tu fais un projet pour chaque partie :
- Ton projet qui contient les entités connaît aucun autre projet.
- Ton projet DAO connaît que ton projet Entités.
- Ton projet Services connaît les projets DAO et Entités .
- Ton projet IHM connaît que le projet Service.

Voila pour mon point de vue .

[ryankarl65]

Personnellement j'ai appris ainsi :

Moi de même, chaque couche est un micro service ou parfois une application

[atha2]

Au final si tu fais un projet pour chaque partie :
- Ton projet qui contient les entités connaît aucun autre projet.
- Ton projet DAO connaît que ton projet Entités.
- Ton projet Services connaît les projets DAO et Entités .
- Ton projet IHM connaît que le projet Service.

Voila pour mon point de vue .

D'accord dans l'ensemble mais pourquoi découper en plusieurs projets ? Un simple découpage en packages et/ou modules devrait être suffisant (sauf pour l'UI évidement)

Moi de même, chaque couche est un micro service ou parfois une application

C'est vraiment ce que tu as appris en cours ? Un peu de lecture additionnelle (par exemple https://martinfowler.com/articles/microservices.html) te ferait le plus grand bien à mon avis.

Sinon pour de grosses applications, je conseille d'au moins jeter un coup d'oeil au DDD (Domain Driven Design). Même si ça peut être assez long à mettre en place, le découpage est très clair. Basiquement on a (je ne parle que du découpage, le DDD c'est plus que ça):
-la couche Interfaces (HTTP, SOAP etc) qui utilise Application
-la couche Application qui implémente les specs fonctionnelles en utilisant Domain (peut déclarer et appeler IMailer, IMessageQueue... mais n'appelle aucune api externe directement)
-la couche Domain (entity, agregat, domain service, IRepository(~= DAO), IFactory), implémente le domaine métier du client, ne dépend de rien du tout (ne connais pas le format de bdd, ne connait aucune api externe)
-la couche Infra (RepositoryImpl, MailerImpl...) qui implémente toutes les interfaces déclarées dans Interfaces, Application et Domain qui accèdent aux API externes. Aucun couche ne dépend explicitement d'Infra.

[Badshade23]

D'accord dans l'ensemble mais pourquoi découper en plusieurs projets ? Un simple découpage en packages et/ou modules devrait être suffisant (sauf pour l'UI évidement).

Exacte, il y a plusieurs possibilités. Actuellement justement j'en fais un avec plusieurs modules en utilisant Maven. Le principe après reste le même.