Bonjour,

Je n'ai pas exactement tout lu, mais j'ai le sentiment qu'on oubli les mots : Data Transfert Object

Citation Envoyé par http://deptinfo.unice.fr/~grin/anciensCours/2005-06/minfo/bdavancees/supports/patternspersistance-dao6.pdf
Un
Data Transfert Object
(DTO) contient l’état
d’un (ou de plusieurs) objet métier, mais pas
son comportement
Ce modèle de conception est utilisé pour

transporter l’état d’un objet entre 2 couches
distantes (sur 2 machines distinctes) dans une
application distribuée
Synonyme :
Transfert Object
(TO)
Il faut éviter les DTOs si l’application est
locale
(complique inutilement
j'aime les conversions cafés entre développeurs, J'ajoute mon point vue perso

POCO ou DTO ont l'unique responsabilité de représenter les données mais pour des "clients" différent :
- POCO est à usage interne mais la principale condition est d’être entièrement découplé de la persistance (décorateur DB, serialisation exit) . De mon point de vue c'est même à découpler de toutes technologies pour garantir la réutilisation (ex. les décorateurs du MVC.NET exit)
- DTO est une représentation "public" pour communiquer avec l’extérieur (souvent marqué par des décorateurs de sérialisation) - utile pour par exemple des applications en WebService ou en MVC.NET/Javascript


Les avantages que je vois des DTO :
- évite de rendre "public" tout l'objet métier et limiter la taille du transfert.
- Évite un lazyloading trop gourmand voir cyclique pendant une serialisation.
- pour du MVC.NET il permet de décorer à volonté sans créer de dépendances improbable entre IHM et objets Métiers.
Inconvenant : devoir écrire des adapateurs.

En ce qui concerne la validation des objets Métiers POCO par eux même.. c'est beaucoup moins claire pour ma part.
Ceci rejoint l’idée de rester POO avec le principe d'encapsulation! cool et j'adhère pour le coup.
Mais es que la représentation des données ET la validation des données n'est t'il pas deux responsabilités différentes?

De mon expérience j'ai toujours vu séparé dans la couche business.
Cette couche encapsule l’accès à la DAL et donc la couche business à la responsabilité de ne pas demander la sauvegarde de données "daubés".

La validation dispersé dans toutes les couches pour des raisons de perfs mais à quel prix pour la maintenance?!
Le code vie et le principe DRY évite de se retrouver avec un plat de spaghetti bien copieux en maintenance.
Malheureusement je suis comme beaucoup, je mets DRY au placard.

Je ne trouve pas de solutions satisfaisantes pour endiguer le problème.


++