Discussion :

[damien77]

Bonjour,

j'aimerai avoir un peu d'aide sur le développement de mon application et surtout savoir si je part sur de bonne base.
Donc je veux réaliser une application sur 3 couches :
Présentation <-> Métier <-> Données.

- Présentation j'implémente le pattern MVC. et le modèle accède a la couche données pour les traitements. (Les contrôles d'erreus font-ils parties de la couche présentation ou métier ?)
Pour communiquer entre la présentation et métier j'utiliser des DTO.

- la couche donnée implémente DAO...

- La couche Métier retourne des DTO à la présentation, des référence vers les DAOService et stocke des objets métiers retourner par les DAOService.

Les OM s'occupe de la création en interne des DTO.

Ce type de développement vous semblent-ils correct ou bien des lacunes existes ?


merci

[Patriarch24]

À quoi te servent donc les DTO ? Tu devrais avoir des objets métiers (POJO), tu n'as sans aucun doute pas besoin de DTO..

Les contrôles d'erreus font-ils parties de la couche présentation ou métier

Couche métier bien entendu !

[yann2]

Salut

J'ai un peu de mal à comprendre ce que tu essaies d'expliquer et j'ai un avis qui diverge de celui de Patriarch24

Au sujet des validations
Pour moi (ou de ce que j'ai pu lire, voir, employer ; soyons honnêtes) il y a deux types de validations :

• Validation des entrées utilisateurs
• Validation des règles métier

La première se réalise aussi bien dans la partie présentation que dans la partie métier. Il s'agit de valider qu'un champs requis à bien été renseigné ou encore de vérifier la taille d'une chaine de caractères ou son format (pour les emails par exemple).
La seconde valide les règles métier et se fait donc dans la couche correspondante. Exemple de règle : Un compte bancaire a au moins un propriétaire. Si le propriétaire d'un compte bancaire est mineur, le solde du compte ne peut descendre en dessous de 15€, etc.

Pour les DTO, ils peuvent très bien être utilisés si il ne s'agit pas d'une bête recopie des Objets Métier (dans ce cas pourquoi s'embêter à gérer la synchro DTO/OM). Si les DTO sont une bête recopie des objets métier, je rejoins l'avis de Patriarch24

Pour rappel (http://en.wikipedia.org/wiki/Data_Transfer_Object)

Data Transfer Objects (DTO), formerly known as Value Objects or VO, are a design pattern used to transfer data between software application subsystems. DTOs are often used in conjunction with Data Access Objects to retrieve data from a database.

The difference between Data Transfer Objects and Business Objects or Data Access Objects is that a DTO does not have any behaviour except for storage and retrieval of its own data (accessors and mutators).

De ce que j'ai compris de ton architecture, les DTO correspondent au Modèle de ta vue présentation. Dans ce cas je ne vois pas de soucis quant à leur utilisation.

Par contre j'ai rien compris à ça :

La couche Métier retourne des DTO à la présentation, des référence vers les DAOService et stocke des objets métiers retourner par les DAOService.

Je pense que si tu avais pris le temps de te relire et de reformuler (quitte à joindre des diagrammes), tu aurai eu plus de réponses
La couche métier retourne des références vers les DAOService ? huh ! qu'est ce que ça veut dire ???? la présentation va recevoir des références vers les DAOService !! J'imagine que non ! Sinon pourquoi s'embêter à faire une architecture en couche.

Bref de ce que j'ai compris, tu as qq chose comme ça : (en mode texte parce que, pour le coup, moi non plus je n'ai pas envie de me fouler )

Code :

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

1
2
Présentation<--DTO (modèle du MVC)-->Service/Métier<----OM---->Accès aux données
Vue----Contrôleur_________________Service/Use Case__________Persistance

et tes services gardent l'état des Objets Métiers lors du déroulement d'un Use Case.

Si c'est bien ça, ça me parait bien. Mais ça fait un moment que je ne fais plus d'appli de gestion. Attendons la validation d'experts

Yann

[inconnu652000]

Si ton appli est conséquente pense à intercaler une couche applicative entre la couche présentation et métier.
Pourquoi ? tout simplement car tu seras tôt ou tard confronter à un cas d'utilisation multi domaine (genre tu doit acceder au facture, client, produit ... en même temps) donc tu vas fortement imbriquer au sein d'une même classe des règles métier liées à des domaines différents.

Dans ta couche métier chaque classe est liées à un domaine. La couche applicative appelle les méthodes des classes métiers pour réaliser l'objectif métier (le cas d'utilisation). La couche métier renvoi les objets métiers et c'est la couche applicative qui les transforme en DTO. De cette manière tu as des COMPOSANTS et en faisant attention tu peux t'assurer qu'ils soient au maximum indépendant. Idéalement, d'ailleurs les méthodes des classes applicative porte souvent le nom de cas d'utilisation.


Ensuite introduire les DTO est une trés bonne chose ! Les DTO sont liés à la couche qui les utilise. Donc il sont liés à ta présentation pour ton cas. C'est une transformation du graphe d'objet métier en un graphe qui est liés à ce que tu affiches et seuleument à ce que tu affiches.

Il faut les utiliser ABSOLUMENT et de façon JUDICIEUSE si ta couche DAO utilise des ORM comme hibernate.

Les OM ne doivent pas contenir la transformation, contrairement à ce que tu dis. Ces sont des classes à part ou la couche applicative qui doit le faire.

Les OM doivent rester des POJO purs et n'embarquer que les règles métier
stable à trés longue durée de vie (exemple : majorité <==> age > 18 ans).
Les classes métiers embarquent la quasi totalité des autres règles métier.

Il faut utiliser les interfaces, c'est ce que tu vas développer en premier. Ces interfaces correspondent au besoin de l'appli et correspond au contrat que doit remplir chaque couche. càd qu'une couche A ne connait que les interfaces de la couche B qui est en dessous.

De cette façon tu réalises une appli hautement découplée de l'IHM et de la persistance. De plus tu peux même paralléliser le travail.