3.9 KiB
Data Transfer Object
Les DTO sont basés sur un pattern de programmation qui tend à transférer des informations depuis une source de données au travers d'objets "simples". Ces classes sont sensées n'avoir aucune implémentation de comportement, aucune connaissance de la couche de persistance, et doivent juste transporter les valeurs. Dans une version plus simple, on pourrait les apparenter à des ViewModel.
Je me pose la question, après avoir écumé plusieurs types d'architectures. D'abord en partant sur une API à base de SqlDataReader et de SqlCommand.
Flexibilité? Nulle, et beaucoup de copier/coller de code à base de SqlConnection.Open(), .Execute() et .Close().
Tout est lié à la base de données et à son type, les lignes de codes se ressemblent toutes et les paramètres de connexion sont placés directement au niveau du code, sans fichier de configuration.
Ensuite, j'ai amélioré le code en implémentant un pseudo-Repository Pattern. A nouveau, beaucoup de méthodes se ressemblaient, et je me suis demandé s'il n'était pas possible de factoriser cette partie-là. C'est là qu'est intervenue la librairie PetaPoco: en générant automatiquement une partie du code au travers de procédures T4 (Text Template Transformation Toolkit), cela m'a permis de la couche d'accès, en créant automatiquement une série de méthodes sur chaque classe, un peu à la manière d'ActiveRecord.
Comme ce sont des objets complexes, j'ai créé (par facilité) des relations entre une instance et ses relations grâce un simili LazyLoading: lorsqu'on accède à une propriété d'une instance pour la première fois, une requête est faite et le résultat est stocké dans un champ de cette instance. En deux mots: mauvaise idée. La structure de mes données étant générique par définition (chaque instance possède un parent, sur une infinité de niveaux), la construction de l'arborescence nécessitait autant de requêtes qu'il y avait de niveaux traversés.
A ce moment-là, je suis revenu vers un modèle plus complexe, type Repository:
- les dépôts permettent d'accéder à un domaine de mon application,
- les méthodes définissent un et un seul point d'entrée pour l'accès à mes données.
Parmi les sources :
- DTOs Best Practices
- Best practices for mapping DTOs to Domain Objects
- Data Transfer Objects by Martin Fowler
- POCO as a LifeStyle
- POCO vs. DTO
- Automapper
- Validating best practices, property vs. dto, simple type vs. object
- Pros and cons of Data Transfert Objects
- On DTOs
- Best practice multilayer architecture and dtos
- How evil are actually data transfer objects
- Rethinking best practices: DTOs, Session Facade